The point on the JS based SRP is insecure is not to say that it is less secure than a password based approach, only that it is not any more secure (if you can defeat TLS as would be required to sniff password, then you can also inject any alternative SRP implementation you like).
In terms of the attacks on the TLS protocol itself, every time there was a 'business as usual' fix for it within the site operator's control.
The general problem as it stands is that to justify the need for browser based SRP, a site must figure *itself* to be incompetent and/or a bad actor, because the only things it adds protection against is site admin explicitly screwing things up, and few people are inclined to factor that in.
It could change if browser native implementations meant you could tell those site operators that they could defend users from their own screw ups, but as it stands correctly implemented (and yes that 'correctly' warrants some humility, but we speak to reality) strategies can mitigate everything that JS based SRP can.
Further, if you don't have the password, you don't have the ability to 'save the user' from their own bad choices, which is frequently a demand of security teams.
Of course, at the end of the day, SRP based on passwords is still subject to the weak link of human selected passwords, which is why the broader industry focuses more on strategies that involve private keys or machine generated shared secrets than wanting to focus too much on secret material derived from some human originated data alone.
What possible use is having a feature for this for applications like dishwashers, dryers, vacuums, washers, and at least some of the others?
Even for most of the rest, I'd personally rather wish for a more modular approach (rather than a connected 'refrigerator', how about a camera to put inside my refrigerator that doesn't drag down a thousand dollar appliance when it fails)?
I could see things like security systems, doorbells (really just more security system), oven (was it left on?), but a lot of this seems useless.
Having the range is not so much something others can't do, it's something they don't think they need to do. From deciding to add range, it wouldn't take them more than 2-3 years to release a product.
On the supercharger stations, various restaurants and shopping malls in my area have charging spots with J1772 spots. In terms of places to do charging, there are already more places to charge per square mile that works with anything than there are Tesla specific stations, at least in my area. I will say that I can't figure out how to identify such restaurants on a map yet, compared to being able to find Tesla stations, but in time I imagine it will be as easy as finding a gas station. This will be the model of electric car charging for long haul trips: charging capability as a feature of a restaurant, not "just like a gas station". It's just so much easier and safer to do electric charging than refueling, so it can be a cheap add-on to a restaurant. On the flip side, even a 15 minute charging time is too long for a 'gas station' like experience, and so we have to move beyond that for electric (in my mind, good riddance).
I think it's a neat endeavor, but success with their current approach is impossible.
Today I can hop in my gas car and take a long trip and not even think about gas for the most part. I can wait until I'm at 30 miles of range to even begin thinking about where to stop, and a gas station will be within eyeshot. within 10 miles generally. That is *insane* amount of coverage, and is only possible through having a diverse set of suppliers owing to utterly standardized fuel. It's also only possible because they turned the fact you are going to stop and be out of your vehicle to a secondary business opportunity to do some shopping.
Now as an experiment, I plugged the only route I routinely would make into navigation and searched along route for a supercharger station. There was one, so I have to plan my charging capacity according to be able to make it the first 200 miles before I start. It will require me to go about 10 minutes out of my way, so I have to have it baked into my route. There are *no* restaurants within a 2 mile radius of the supercharger station. To their credit, I actually could search this sort of thing, I cannot yet search for how to make the trip with competing electric cars (or at least I couldn't figure out how) So their massive investment has made something that would have been implausible a hassle, which is good, but I don't think it will be an enduring advantage.
People keep imagining the model to be exactly gas station like. Unlike gas stations, any grocery store or eatery can relatively cheaply add decent charging capacity. The added time taken compared to gasoline is a problem, but it's also not something that requires managing the logistics of tanker trucks, complex fuel storage tanks, and you can just leave your car plugged in unattended with electricity. As electric cars gain popularity, the usual solution for long trips will be stop at a place to eat that spent a few thousand dollars to add charging capability to their lot, at first to draw in the people with electric cars, eventually because everywhere else will offer that.
If the intent behind the question is to erode investor confidence in the company, then he plays into the hands of the person supporting the short position. Whether he gets an answer reinforcing that "yes, people are abandoning the model 3 as a product" or makes Musk say "boring, next!", the effect is the same: the people would would invest in a non-short position are made to be concerned. Providing an actual answer to the question that would reveal it to be completely irrelevant to the success of the company given actual facts and would build confidence in the investors he wants.
He did, and he used it. What are you crying about?
No, he moved on and the next day between him and a lot of Tesla fans they came up with a response. The stock recovered for the most part, but it did take a dive for a bit and general concerns about Musk are reinforced. It does not help him for everyone to white knight for him at the vaguest hint of constructive criticism, he's an adult, he should be able to see this and learn from it, but can be dis served if there's too much of a loud echo chamber telling him that he is always the best all the time.
We have a diverse population, full of traits that are nothing but a waste now and we would want to eliminate them.
Obesity (to the extent it is truly genetic anyway) is a horrible detriment and everyone wants to have zero jiggle anywhere on their body. Some circumstance comes along and will result in a food gap of about 3 months, only the obese *might* survive (people saying obese people have a lot of problems that will kill them first are accurate, but they are the only ones with enough built in fat stores to even theoretically make it, even if the vast majority of them would die too)..
Having a diverse set of traits in the population to accommodate the unexpected is valuable, but that's not the way we think about things when we go to 'engineer' our population. We also don't want to plan for people who are needed, but not rare today (no one would design their kid to be a sanitation worker, but we need those).
At least for the latter, the correct response would be to highlight *on the call* that you have had a buyer for every model 3 that has come off the line and how badly the conversion rate would have to be for there to be a surplus of car production at some timeframe, not to snub the person because the question irritates you as you don't like their agenda. If this is a known agenda, then he should have a succinct yet useful response off the top of his head at this point. On the face of it, it doesn't seem a hard question to address, regardless on his feelings on the motivations behind it.
I think the challenge is that long term, there are signs that there will be plenty of competition in what would be the bread and butter of Tesla's business.
They have been doing a lot and it has been costly, but I wouldn't be so confident that investment will become durable first mover advantage for Tesla, or if it is more the tide that raises all ships.
The issue is that during an earnings call, you field the analyst questions, not indulge feel good fanboyism.
His rationale was that the ones he snubbed were 'sell-side' and therefore just out to screw him over to help those who have shorted stock, which is problematic as that isn't what 'sell-side' means. It seems he doesn't understand that (bad for one having that responsibility) and that he is sore over how many people are shorting Tesla stock, and unable to handle it.
Even if he did feel the analysts were spinning a bad story out to get him for the sake of boosting the fortunes of those holding a short position, the right response would be to face it head on and point out how he feels the narrative implied is inaccurate, not to cut it off, which gives an impression that you don't have a rebuttal for such a story and as such the people advocating a 'short' position are right.
Musk may be unable to provide good business leadership through controversial/rough times.
I'm saying it's a bad idea for society, practically speaking.
Gold rushes manifesting in how people deign the very genetics of their children. If we are lucky, it's a scam that doesn't do anything (which is likely now). If we were able to ingrain some sort of innate suitability for a profession, that first generation is going to be hyper-specialized for work that the previous generation estimated would be the 'hot job'.
That aside, think of how much worse the stage parents are going to be, and how useless someone would be if we could indulge such parents in getting exactly what they want.
All this before the ethical issue how much it would suck for the previous generation to have micromanaged your life choices down to the very fabric of your being (which is an overstatement of what we can achieve right now, but speaking to the ambition).
As it stands, random chance is better at keeping us prepared for a flexible future than we would be on the whole.
At least up to some point of adoption, don't even need to worry about batteries. When my house is pumping out 5 kW more than I'm using, then I'm pretty much powering three houses that do not have solar capacity (and at least where I live, the power company has to credit my bill accordingly, and my house has a pretty good surface area exposes to the sun so it can produce a lot of wattage). If hypothetically over 30-40% of homes have adopted solar, then we have to either store or dump excess power, but that's a bridge to cross when we come to it.
It's one thing to eliminate debilitating genetic conditions.
It's another to have designer genetics, carefully controlling height, eye color, hair color, whatever, things that in no way constrain ability to live, just a different cosmetic desire.
It's even worse to go to 'I want to design my baby for STEM', you are now going to the point of deciding a career path right at the time of being an embryo.
At least some may, but I know that at least some companies do not do that.
Also, a Chinese company with significant US engineering presence can be in the exact same boat of having skilled US engineers watching for issues, but the presumption is that the executives matter, not the engineers.
The problem I've seen is that some people have called out idiocy without even *knowing* the person's race or gender, and *still* got accused of racism/sexism when the race/sex of the insulted one is highlighted in the aftermath.
In the second argument, it can come down to what is considered 'unnecessarily' cruel and disrespectful. This rather subjective thing can became a problem when two people simply disagree. Even if it's a purely technical difference of opinion, people take things personally and will either avoid saying something they should say out of desire to be polite, or start painting a reasonable discussion as insensitive because one party doesn't agree.
The 'good' example would also run afoul of some codes of contacts, as the tone may be considered too rude.
Also, when someone is rude to someone else, without even *knowing* their race/gender identity/etc, the offended person has on occasion asserted they were the target of hurtful language because of their situation relative to one of those groups, despite lack of any hint of references to that early on.
You are sorely mistaken if you think American executive is in any way a deterrent from China attempting anything. Not to say China would do it, but the American execs are too busy counting their money to care or delegate caring about what their Chinese suppliers are doing.
From China's perspective, they have so many channels to inject things into the supply chains through component vendors no one has even heard of, and under less scrutiny than Huawei. I think the risk from the things not even enumerated exceed the risk from Huawei. Huawei has much higher value to be made 'proof' that China can make a dominant technology company entirely organically without so much help from western companies (contrast to Lenovo, which purchased western assets from IBM and even 'westernized' their own name, China's government would probably much rather have the organic, unapologetically Chinese Huawei be what people think of when they think Chinese tech company).
Problem with SRP is that it's not particularly useful in a browser, practically speaking.
The implementation actually performing the SRP is going to be a javascript download from the site you are dealing with. Meaning the server and connection you explicitly do not trust to send your password to is the one you are trusting to provide the alternative implementation.
Doing SRP right requires a lot of work that just isn't happening. Namely browsers particularly need to implement some sort of industry standard integration of the concept so that the connection can't tamper with the client side implementation. However it's a chicken and egg problem, they don't do it because no one uses it and no one uses it because they don't do it.
Also, the migration would be another one of those huge pains. Many browsers unable to do SRP the hypothetically standard way alongside the standard SRP clients to support. Would need to be able to support users who have not logged in for a while to provide data to calculate a new version of their password whilst simultaneously proving they know the old password, and having that mechanism not be susceptible to defeat SRP.
Also have to sort out how to do the password entry UI, as users have been trained that the stock user/password prompt in a browser is a sign of weak and/or lazy security and sites have become accustomed to personalizing even the login experience (for branding purposes and to make users feel like the site takes security more seriously, despite no technical reason for that impression being valid).
All this to solve a problem that the wider community generally considers 'solved' already by good certificate discipline and avoiding any non-ephemeral treatment of passwords. Of course this very article is an example of how even respectable organizations screw up that latter half. In any event, the widely held perception is that SRP is not enough worth it to do it right, that if not done right it's not worth doing, and switching to various dressings of key based authentication is better anyway.
TLS-SRP http would be in particular an amazingly better solution for a lot of 'internal network' use cases for TLS where the CA model particularly falls short, but it's just not in the cards as things stand today.
Generally speaking, if a scheme means the server is never handed the password at all, then a compromise of their database leaks a viable set of credentials to use to log into their service. The alternative to one-way hashing, with password provided to validate knowledge of the password is generally some variation of shared secret, where the server must have the same knowledge the client has. It may be a secret derived from the password and thus the password is still not known, but it's of small comfort when you don't actually need to know the password to authenticate.
The only approach today that at least superficially involves a password without these pitfalls would be a password locally unlocking a private key and using key based authentication instead (in which case the entire password situation is unknown to the server), but without some sort of recovery mechanism, you would have a lot of users losing their private key material one way or another without a good recovery option.
For my part I don't take issue with the concept that at this point encryption and integrity assurance for this sort of traffic, even internal isn't such a bad idea. Aspiring to have an internal network that isn't going to be compromised at the IP or DNS level is a good goal, but to the extent possible success should not be assumed. As such it would be bad form to assume a network to be 'trusted' if at all possible.
As it stands, not many folks will say 'ssh is stupid, just use telnet' because the key management isn't particularly onerous, despite offering the same sort of security benefits as TLS. People will complain that first contact between a given ssh client and ssh server pair is rarely ever secured, but as far as compromises go, it isn't so shabby. Additionally, SSH in practice has a number of facilities for the willing to do some sort of relevant PKI to mitigate that concern.
Structurally, the use of certificates in TLS can enable a superset of the way SSH keys can be managed. The private/public keypairs are there as it is in SSH, but with facilities to allow third party trust relationships too. The problem is the state of applications, libraries, and best practices end up making people blindly accepting connection every time or installing very broad CA certificates. I've even heard of one place signing a wildcard certificate and passing the related private key around everywhere so they wouldn't have to 'fool with it' and just have every device have the exact same keypair. TLS is frustrating because of these limitations *in practice*, but I'd rather see a better usage model for the key management than to ditch the concept entirely.
Of course, you would have to securely carry over that cert. At that point it wouldn't matter if it were self signed or not, it's more like managing an ssh host key. Problem is that in practice, people will click 'yes'. Chrome sucks in the regard of not allowing me to mark a specific fingerprint as 'valid' regardless of CA validation.
Would have been nice to link in the article, it took me a while to find it. So this provides a more targeted way to relax the CT, which can in turn limit the efficacy of that internal CA, so it seems to be a step in the positive direction.
Good to see progress being made in limiting the collateral damage enabling https internally can inflict, but it's still in many ways convoluted and an ill fit for how many teams do internal IT.
Seemingly on a domain level. So long as you have domain names...
It would be interesting to treat IP based urls different from name based urls somehow... or at least private and link local addresses somehow differently (unless resolved by name)
The CA model is particularly bad for 'internal' devices.
So one, for internal communications inside a home network, the warning is so scary that some devices decline to support https just to avoid the support call because a web browser called the device 'insecure'. Note that https with bad cert is considered 'terribly insecure to the point of blocking the site' and http without any cert whatsoever is 'ok'. Home networks are not going to go through the rigmarole of all this.
For another, my internal IT department is given the ability to sign a certificate for *any* site I visit to provide support for internal devices. I am not empowered as a user to elect to impose my own nameConstraints as I import the certificate, so to secure access to router.internal.mycompany.com, I give them access to impersonate my.bank.com
Even when the IT department has ability to sign certificates, either it's going to be uselessly lax (automatic granting of certs for whatever reason) or impractically difficult (every sign requires tedious interactions). Companies are terrible about implementing the right balance internally.
Assuming you overcame all this, you *still* will get a warning, because that internal IT department isn't going to have it registered in a CT log. If they *do*, then others can audit that log to discern details about their network and they have *another* class of security problem to tackle. Or chrome is deployed with a policy to disable this feature for the sake of the internal devices, *again* coming back to fixing internal network behavior requiring reducing security for the wider internet.
The problem is that roughly all discussions on this front focus on the typical 'internet' usage and fail to conceive of approaches that would make sense for internal networks.
1) Z may be *way* better suited to make Y happen, and not everyone knows about Z. 2) Often there is a question behind the question. Answering the microscopic part of someone's set of problems may lead them to pretty convoluted places, compared with a wider context where a more consistent and easy approach may be had.
Slashdot Mirror
The point on the JS based SRP is insecure is not to say that it is less secure than a password based approach, only that it is not any more secure (if you can defeat TLS as would be required to sniff password, then you can also inject any alternative SRP implementation you like).
In terms of the attacks on the TLS protocol itself, every time there was a 'business as usual' fix for it within the site operator's control.
The general problem as it stands is that to justify the need for browser based SRP, a site must figure *itself* to be incompetent and/or a bad actor, because the only things it adds protection against is site admin explicitly screwing things up, and few people are inclined to factor that in.
It could change if browser native implementations meant you could tell those site operators that they could defend users from their own screw ups, but as it stands correctly implemented (and yes that 'correctly' warrants some humility, but we speak to reality) strategies can mitigate everything that JS based SRP can.
Further, if you don't have the password, you don't have the ability to 'save the user' from their own bad choices, which is frequently a demand of security teams.
Of course, at the end of the day, SRP based on passwords is still subject to the weak link of human selected passwords, which is why the broader industry focuses more on strategies that involve private keys or machine generated shared secrets than wanting to focus too much on secret material derived from some human originated data alone.
What possible use is having a feature for this for applications like dishwashers, dryers, vacuums, washers, and at least some of the others?
Even for most of the rest, I'd personally rather wish for a more modular approach (rather than a connected 'refrigerator', how about a camera to put inside my refrigerator that doesn't drag down a thousand dollar appliance when it fails)?
I could see things like security systems, doorbells (really just more security system), oven (was it left on?), but a lot of this seems useless.
Having the range is not so much something others can't do, it's something they don't think they need to do. From deciding to add range, it wouldn't take them more than 2-3 years to release a product.
On the supercharger stations, various restaurants and shopping malls in my area have charging spots with J1772 spots. In terms of places to do charging, there are already more places to charge per square mile that works with anything than there are Tesla specific stations, at least in my area. I will say that I can't figure out how to identify such restaurants on a map yet, compared to being able to find Tesla stations, but in time I imagine it will be as easy as finding a gas station. This will be the model of electric car charging for long haul trips: charging capability as a feature of a restaurant, not "just like a gas station". It's just so much easier and safer to do electric charging than refueling, so it can be a cheap add-on to a restaurant. On the flip side, even a 15 minute charging time is too long for a 'gas station' like experience, and so we have to move beyond that for electric (in my mind, good riddance).
I think it's a neat endeavor, but success with their current approach is impossible.
Today I can hop in my gas car and take a long trip and not even think about gas for the most part. I can wait until I'm at 30 miles of range to even begin thinking about where to stop, and a gas station will be within eyeshot. within 10 miles generally. That is *insane* amount of coverage, and is only possible through having a diverse set of suppliers owing to utterly standardized fuel. It's also only possible because they turned the fact you are going to stop and be out of your vehicle to a secondary business opportunity to do some shopping.
Now as an experiment, I plugged the only route I routinely would make into navigation and searched along route for a supercharger station. There was one, so I have to plan my charging capacity according to be able to make it the first 200 miles before I start. It will require me to go about 10 minutes out of my way, so I have to have it baked into my route. There are *no* restaurants within a 2 mile radius of the supercharger station. To their credit, I actually could search this sort of thing, I cannot yet search for how to make the trip with competing electric cars (or at least I couldn't figure out how) So their massive investment has made something that would have been implausible a hassle, which is good, but I don't think it will be an enduring advantage.
People keep imagining the model to be exactly gas station like. Unlike gas stations, any grocery store or eatery can relatively cheaply add decent charging capacity. The added time taken compared to gasoline is a problem, but it's also not something that requires managing the logistics of tanker trucks, complex fuel storage tanks, and you can just leave your car plugged in unattended with electricity. As electric cars gain popularity, the usual solution for long trips will be stop at a place to eat that spent a few thousand dollars to add charging capability to their lot, at first to draw in the people with electric cars, eventually because everywhere else will offer that.
If the intent behind the question is to erode investor confidence in the company, then he plays into the hands of the person supporting the short position. Whether he gets an answer reinforcing that "yes, people are abandoning the model 3 as a product" or makes Musk say "boring, next!", the effect is the same: the people would would invest in a non-short position are made to be concerned. Providing an actual answer to the question that would reveal it to be completely irrelevant to the success of the company given actual facts and would build confidence in the investors he wants.
He did, and he used it. What are you crying about?
No, he moved on and the next day between him and a lot of Tesla fans they came up with a response. The stock recovered for the most part, but it did take a dive for a bit and general concerns about Musk are reinforced. It does not help him for everyone to white knight for him at the vaguest hint of constructive criticism, he's an adult, he should be able to see this and learn from it, but can be dis served if there's too much of a loud echo chamber telling him that he is always the best all the time.
We have a diverse population, full of traits that are nothing but a waste now and we would want to eliminate them.
Obesity (to the extent it is truly genetic anyway) is a horrible detriment and everyone wants to have zero jiggle anywhere on their body. Some circumstance comes along and will result in a food gap of about 3 months, only the obese *might* survive (people saying obese people have a lot of problems that will kill them first are accurate, but they are the only ones with enough built in fat stores to even theoretically make it, even if the vast majority of them would die too)..
Having a diverse set of traits in the population to accommodate the unexpected is valuable, but that's not the way we think about things when we go to 'engineer' our population. We also don't want to plan for people who are needed, but not rare today (no one would design their kid to be a sanitation worker, but we need those).
At least for the latter, the correct response would be to highlight *on the call* that you have had a buyer for every model 3 that has come off the line and how badly the conversion rate would have to be for there to be a surplus of car production at some timeframe, not to snub the person because the question irritates you as you don't like their agenda. If this is a known agenda, then he should have a succinct yet useful response off the top of his head at this point. On the face of it, it doesn't seem a hard question to address, regardless on his feelings on the motivations behind it.
I think the challenge is that long term, there are signs that there will be plenty of competition in what would be the bread and butter of Tesla's business.
They have been doing a lot and it has been costly, but I wouldn't be so confident that investment will become durable first mover advantage for Tesla, or if it is more the tide that raises all ships.
The issue is that during an earnings call, you field the analyst questions, not indulge feel good fanboyism.
His rationale was that the ones he snubbed were 'sell-side' and therefore just out to screw him over to help those who have shorted stock, which is problematic as that isn't what 'sell-side' means. It seems he doesn't understand that (bad for one having that responsibility) and that he is sore over how many people are shorting Tesla stock, and unable to handle it.
Even if he did feel the analysts were spinning a bad story out to get him for the sake of boosting the fortunes of those holding a short position, the right response would be to face it head on and point out how he feels the narrative implied is inaccurate, not to cut it off, which gives an impression that you don't have a rebuttal for such a story and as such the people advocating a 'short' position are right.
Musk may be unable to provide good business leadership through controversial/rough times.
I'm saying it's a bad idea for society, practically speaking.
Gold rushes manifesting in how people deign the very genetics of their children. If we are lucky, it's a scam that doesn't do anything (which is likely now). If we were able to ingrain some sort of innate suitability for a profession, that first generation is going to be hyper-specialized for work that the previous generation estimated would be the 'hot job'.
That aside, think of how much worse the stage parents are going to be, and how useless someone would be if we could indulge such parents in getting exactly what they want.
All this before the ethical issue how much it would suck for the previous generation to have micromanaged your life choices down to the very fabric of your being (which is an overstatement of what we can achieve right now, but speaking to the ambition).
As it stands, random chance is better at keeping us prepared for a flexible future than we would be on the whole.
At least up to some point of adoption, don't even need to worry about batteries. When my house is pumping out 5 kW more than I'm using, then I'm pretty much powering three houses that do not have solar capacity (and at least where I live, the power company has to credit my bill accordingly, and my house has a pretty good surface area exposes to the sun so it can produce a lot of wattage). If hypothetically over 30-40% of homes have adopted solar, then we have to either store or dump excess power, but that's a bridge to cross when we come to it.
It's one thing to eliminate debilitating genetic conditions.
It's another to have designer genetics, carefully controlling height, eye color, hair color, whatever, things that in no way constrain ability to live, just a different cosmetic desire.
It's even worse to go to 'I want to design my baby for STEM', you are now going to the point of deciding a career path right at the time of being an embryo.
At least some may, but I know that at least some companies do not do that.
Also, a Chinese company with significant US engineering presence can be in the exact same boat of having skilled US engineers watching for issues, but the presumption is that the executives matter, not the engineers.
The problem I've seen is that some people have called out idiocy without even *knowing* the person's race or gender, and *still* got accused of racism/sexism when the race/sex of the insulted one is highlighted in the aftermath.
In the second argument, it can come down to what is considered 'unnecessarily' cruel and disrespectful. This rather subjective thing can became a problem when two people simply disagree. Even if it's a purely technical difference of opinion, people take things personally and will either avoid saying something they should say out of desire to be polite, or start painting a reasonable discussion as insensitive because one party doesn't agree.
The 'good' example would also run afoul of some codes of contacts, as the tone may be considered too rude.
Also, when someone is rude to someone else, without even *knowing* their race/gender identity/etc, the offended person has on occasion asserted they were the target of hurtful language because of their situation relative to one of those groups, despite lack of any hint of references to that early on.
You are sorely mistaken if you think American executive is in any way a deterrent from China attempting anything. Not to say China would do it, but the American execs are too busy counting their money to care or delegate caring about what their Chinese suppliers are doing.
From China's perspective, they have so many channels to inject things into the supply chains through component vendors no one has even heard of, and under less scrutiny than Huawei. I think the risk from the things not even enumerated exceed the risk from Huawei. Huawei has much higher value to be made 'proof' that China can make a dominant technology company entirely organically without so much help from western companies (contrast to Lenovo, which purchased western assets from IBM and even 'westernized' their own name, China's government would probably much rather have the organic, unapologetically Chinese Huawei be what people think of when they think Chinese tech company).
Problem with SRP is that it's not particularly useful in a browser, practically speaking.
The implementation actually performing the SRP is going to be a javascript download from the site you are dealing with. Meaning the server and connection you explicitly do not trust to send your password to is the one you are trusting to provide the alternative implementation.
Doing SRP right requires a lot of work that just isn't happening. Namely browsers particularly need to implement some sort of industry standard integration of the concept so that the connection can't tamper with the client side implementation. However it's a chicken and egg problem, they don't do it because no one uses it and no one uses it because they don't do it.
Also, the migration would be another one of those huge pains. Many browsers unable to do SRP the hypothetically standard way alongside the standard SRP clients to support. Would need to be able to support users who have not logged in for a while to provide data to calculate a new version of their password whilst simultaneously proving they know the old password, and having that mechanism not be susceptible to defeat SRP.
Also have to sort out how to do the password entry UI, as users have been trained that the stock user/password prompt in a browser is a sign of weak and/or lazy security and sites have become accustomed to personalizing even the login experience (for branding purposes and to make users feel like the site takes security more seriously, despite no technical reason for that impression being valid).
All this to solve a problem that the wider community generally considers 'solved' already by good certificate discipline and avoiding any non-ephemeral treatment of passwords. Of course this very article is an example of how even respectable organizations screw up that latter half. In any event, the widely held perception is that SRP is not enough worth it to do it right, that if not done right it's not worth doing, and switching to various dressings of key based authentication is better anyway.
TLS-SRP http would be in particular an amazingly better solution for a lot of 'internal network' use cases for TLS where the CA model particularly falls short, but it's just not in the cards as things stand today.
Generally speaking, if a scheme means the server is never handed the password at all, then a compromise of their database leaks a viable set of credentials to use to log into their service. The alternative to one-way hashing, with password provided to validate knowledge of the password is generally some variation of shared secret, where the server must have the same knowledge the client has. It may be a secret derived from the password and thus the password is still not known, but it's of small comfort when you don't actually need to know the password to authenticate.
The only approach today that at least superficially involves a password without these pitfalls would be a password locally unlocking a private key and using key based authentication instead (in which case the entire password situation is unknown to the server), but without some sort of recovery mechanism, you would have a lot of users losing their private key material one way or another without a good recovery option.
For my part I don't take issue with the concept that at this point encryption and integrity assurance for this sort of traffic, even internal isn't such a bad idea. Aspiring to have an internal network that isn't going to be compromised at the IP or DNS level is a good goal, but to the extent possible success should not be assumed. As such it would be bad form to assume a network to be 'trusted' if at all possible.
As it stands, not many folks will say 'ssh is stupid, just use telnet' because the key management isn't particularly onerous, despite offering the same sort of security benefits as TLS. People will complain that first contact between a given ssh client and ssh server pair is rarely ever secured, but as far as compromises go, it isn't so shabby. Additionally, SSH in practice has a number of facilities for the willing to do some sort of relevant PKI to mitigate that concern.
Structurally, the use of certificates in TLS can enable a superset of the way SSH keys can be managed. The private/public keypairs are there as it is in SSH, but with facilities to allow third party trust relationships too. The problem is the state of applications, libraries, and best practices end up making people blindly accepting connection every time or installing very broad CA certificates. I've even heard of one place signing a wildcard certificate and passing the related private key around everywhere so they wouldn't have to 'fool with it' and just have every device have the exact same keypair. TLS is frustrating because of these limitations *in practice*, but I'd rather see a better usage model for the key management than to ditch the concept entirely.
Of course, you would have to securely carry over that cert. At that point it wouldn't matter if it were self signed or not, it's more like managing an ssh host key. Problem is that in practice, people will click 'yes'. Chrome sucks in the regard of not allowing me to mark a specific fingerprint as 'valid' regardless of CA validation.
One amendment, that CT policy is better than I presumed it would be:
http://www.chromium.org/admini...
Would have been nice to link in the article, it took me a while to find it. So this provides a more targeted way to relax the CT, which can in turn limit the efficacy of that internal CA, so it seems to be a step in the positive direction.
Good to see progress being made in limiting the collateral damage enabling https internally can inflict, but it's still in many ways convoluted and an ill fit for how many teams do internal IT.
http://www.chromium.org/admini...
Seemingly on a domain level. So long as you have domain names...
It would be interesting to treat IP based urls different from name based urls somehow... or at least private and link local addresses somehow differently (unless resolved by name)
The CA model is particularly bad for 'internal' devices.
So one, for internal communications inside a home network, the warning is so scary that some devices decline to support https just to avoid the support call because a web browser called the device 'insecure'. Note that https with bad cert is considered 'terribly insecure to the point of blocking the site' and http without any cert whatsoever is 'ok'. Home networks are not going to go through the rigmarole of all this.
For another, my internal IT department is given the ability to sign a certificate for *any* site I visit to provide support for internal devices. I am not empowered as a user to elect to impose my own nameConstraints as I import the certificate, so to secure access to router.internal.mycompany.com, I give them access to impersonate my.bank.com
Even when the IT department has ability to sign certificates, either it's going to be uselessly lax (automatic granting of certs for whatever reason) or impractically difficult (every sign requires tedious interactions). Companies are terrible about implementing the right balance internally.
Assuming you overcame all this, you *still* will get a warning, because that internal IT department isn't going to have it registered in a CT log. If they *do*, then others can audit that log to discern details about their network and they have *another* class of security problem to tackle. Or chrome is deployed with a policy to disable this feature for the sake of the internal devices, *again* coming back to fixing internal network behavior requiring reducing security for the wider internet.
The problem is that roughly all discussions on this front focus on the typical 'internet' usage and fail to conceive of approaches that would make sense for internal networks.
Pfft. Amateur.
I took my 16550 UART and reprogrammed it to be a full speed 256 lane PCIe gen 4 controller.
1) Z may be *way* better suited to make Y happen, and not everyone knows about Z.
2) Often there is a question behind the question. Answering the microscopic part of someone's set of problems may lead them to pretty convoluted places, compared with a wider context where a more consistent and easy approach may be had.