That won't happen, if anything SSL cert's are easier to get now than ever and with projects like letsencrypt.org it will become even easier.
Also many of the malicious adds do not come from malware networks they come from all major ad networks including Google's.
You have ads exploiting zero day vulnerabilities in Flash and browsers that not easy to detect, and with the amount of syndication in ad networks you can't effectively blacklist or revoke them.
One of the downsides to this whole "letsencrypt" movement and CA's from less "organized" countries being accepted by major browsers and clients is that you will have much more failures in security.
SSL was designed around high level of trust and that trust worthy SSL certificates will not be easy to come by, this is why they used to cost so much there was actual inspection and you would get fraud insurance for quite high amounts.
Today i won't be surprised if you could get a Google.com cert from some low tier CA in the Philippines which automates the process and it will be valid on large amount of devices.
We need a better verification system for SSL and actual policing of certificates including integrating it into DNS, if i ask for Google.com i should get a "cert" entry from the DNS server just as i get the A entry for it, and i don't understand why this isn't the case yet.
Because the main thrust of HTTPS at this point is regaining some privacy from snooping governmental organizations more than it is building a trust chain.
In a manner of speaking. Even a self signed certificate prevents you from passive eavesdropping and traffic injection (a thing we know the US government is doing right now) if not an an active man in the middle (something which may or may not be happening to you on the plain HTTP connections you use every day)
Passive eavesdropping yes, injection nope since it's not passive to begin with and unless you can explicitly verify it it's pretty useless.
SSL works because we assume that people can't issue certificates for websites that they do not control which isn't the case.
I'm not trying to keep the internet in plain text, I'm trying to keep the internet a place where i can trust the certificates and not having to worry about a CA in china issuing certificates for the sites i visit because they can be CBA to check.
An attack against a self signed cert may cost more then what ever but that wasn't what we were talking about initially either.
If you can MITM which they can and can get cheap valid certificates it's game over.
And while the NSA might be able to get certificates no matter the case, people have managed to buy certificates for domains they do not own multiple times now.
Which puts the ability to MITM real world SSL sessions in the hands of individuals.
> I'm trying to keep the internet a place where i can trust the certificates
That ship sailed a long time ago. While hierarchical PKI has always been a flawed concept (I find it unlikely that you actually trust all of the organizations that firefox/etc ship as trusted roots). Even if you did, as you aid, these "authorities" have signed improper certs.
Trying to patch holes in this failed system (such as revoking those improper certs) is yet another foolish attempt to enumerate badness[1]. If you want authentication, you need do your own chain-of-trust instead of assuming ~100 cert authorities will do that for you.
> Which puts the ability to MITM real world SSL sessions in the hands of individuals.
So we should keep the world in plaintext (by not allowing self signed certs)?
Quite a few people besides the NSA already[2] MITM connections. My point is that we absolutely need to raise those costs. Even with the NSA, just because they have the capability to do something doesn't mean you should give up. Make the do the extra work of a MitM attck (even if probably a small amount of extra work in the case of the NSA).
Add another categorization if you want. Nobody said you have to treat self-signed certs as secure, just that they need to be used. Privacy from eavesdroppers and authentication are separate goals.
I think we are mostly in agreement, but the problem is that if the attacker can perform a MITM attack then a self signed certificate unless it's explicitly verified is worth less.
I've said that we need to add additional levels of trust to the current PKI/SSL cert system preferably adding DNS records with the hash of the certificates and enforcing DNSSec globally this isn't the best solution but it's just enough of an easy hack that it will work for a good while.
What i do not want to see is people thinking that if we just spam SSL certs and stick them on everything it will some how help us, this is the classical definition of security theater.
When cost reduction isn't sufficient to thwart any effective surveillance, and worse using self signed certs trains people to just click accept, and free SSL certificates make it easier to gain valid certificates in a fraudulent manner things will only become worse not better.
While it's true that authentication and encryption are separate domains with how TLS/SSL is implemented currently they are tied by the hip, if you can't trust the authentication part of SSL the encryption part becomes meaningless to all but the most primitive types of passive sniffing.
If you want to separate them then lets kill TLS all together since PKI for the most part have failed, we can use other pure key exchange mechanism like well implemented DH without all the certificate nonsense.
> self signed certificate unless it's explicitly verified is worth less.
Of course it's worth less; the point is that it's not worthless, and has greater value than plaintext.
> if the attacker can perform a MITM attack
Then you communication is still protected from other attackers.
> What i do not want to see is people thinking that if we just spam SSL certs and stick them on everything
That's exactly the thing that needs to happen. PHK was right when he pointed dout that it would be trivial for Apache to simply generate a self-signed cert on first use if no other cert exists, removing a lot of the plaintext on the the internet.
> it will some how help us
"some how"? The point was it provides very good protection against passive analytics (aka "eavesdropping", "spying").
> this is the classical definition of security theater.
Nonsense, nobody has ever claimed self-signed certificates were "safe", we only said they were better than plaintext. Why would you accept self-signed certificates as any kind of authentication?
> self signed certs trains people to just click accept
sigh
That dialog may be the biggest reason we're still using plaintext. I needs to die yesterday, for the very reason you say: it gives people bad habits. That kind of scary popup needs to be reserved for invalid certificates, which actually warrant that kind of attention. Given BULLRUN's large budget and how easy it is to manipulate software projects[1], it is somewhat suspicious that there just happens to be a scary popup if someone tries to encrypt without caring about authentication.
Nobody said anything about giving self-signed certificates any kind of trust. This is about removing plaintext. Unfortunately, there has been culture that badly confuses authentication with encryption (privacy) when they are entirely separate matters.
> meaningless to all but the most primitive types of passive sniffing.
Which is exactly the set of problems I'm talking about. Why do you want to continue allowing passive sniffing? We can trivially put a stop to this kind of nearly-free eavesdropping, but because those solutions don't address more complicated types of attacks (by design! use authentication when you can!), security people tend to be hostile to the idea. Meanwhile, as the search for a perfect solution continues, incredible amounts of passive sniffing is de facto accepted as the status quo.
I don't think that running plain text services is warranted, but i also do not want to see us rush into a horrible system that will not provide any sufficient protection against surveillance while forming the mindset of people into a false pretense of security.
If we want security we should design a better system not force horrid implementation of already bad system.
What you are doing is like putting the people that we should moderate the use of antibiotics and anti-malaria drugs because of resistances in the same camps as anti-vaccine nut jobs.
I want a better secure Internet, not one that is flooded with out of control certificates and poor implementations which will only make things worse and much harder to untangle in the long run.
And no self-signed certificates aren't better than plain text, unless i have received public key / thumbprint of the certificate through a channel I trust and could verify the sender of that information to me a self signed certificate is equivalent of plain text because the moment I have to accept that connection on good faith i cannot trust that the party which I am communicating it is the party I intended to communicate with or that no one else has the key.
Under those circumstances I will not transfer any information that I would not transfer over plain text period, if you do so well do it at your own peril.
> I don't think that running plain text services is warranted
So stop the fear mongering over self-signed certs so plaintext can simply end.
> while forming the mindset of people into a false pretense of security
Then stop conflating self-signed certificates with a trust system. I'm talking about a replacement for plaintext; this doesn't affect the handling of authenticated certificates in any way.
Since you still seem to not not understand this, let me be explicit: I'm saying we need protect against passive eavesdropping at the network level. I never said you should lie to the use* and claim their connection had any additional security. These fears about a "false pretense of security" are not relevant, as a move from plaintext to opportunistic encryption with self-signed certificates shouldn't be visible to the user.
> I cannot trust that the party which I am communicating it is the party I intended to communicate with or that no one else has the key.
Obviously. I never claimed otherwise. This isn't relevant, and if you want to protect against this threat model, you obviously need proper authentication (which I recommend whenever possible). Currently a lot communication on the internet has authentication risks AND allows anybody with a packet sniffer to log their data for next to no cost? You to believe it's a bad idea to convert those plaintext situations into something that has the same authentication risks while only betraying the contents to a single eavesdropper, who must be a MitM.
There is no technical reason not to do this. As you obviously know because you referenced the certificate warning popup, self-signed certificates are trivially identifiable, so there is no reason to confuse them with normal certificates. Absolutely nothing needs to change in how this is presented to the user, so we aren't creating any sort of false sense of security.
> Under those circumstances I will not transfer any information that I would not transfer over plain text period,
Good for you. What does that have to do with the fact that much of the internet is still filled with the plaintext of people who don't understand this kind of technical topic? Why are you resisting shielding their communications from passive eavesdropping?
This attitude that security must protect against all threats (or at least the treats YOU care about) is a major problem. What do you think is going to happen? It is magical thinking to assume that everyone will suddenly start using full, proper crypto (they can do that right now). We've been trying that for years and the result was a lot of people staying with plaintext.
and worse using self signed certs trains people to just click accept
This is a thing that happens right here, right now. We treat all of the following things as equivalent big scary warnings from the browser regardless of how bad they are or what the impact on security actually is.
* Expiration date d+1day (security impact: NIL)
* Name doesn't match the cert
* CA not trusted
* Certificate is self-signed
* Certificate was generated using old/broken crypto
Weve've got a couple decades of retraining to do because of this boneheaded, "wolf-crying" design.
* Expiration date d+1day (security impact: NIL) > not much impact unless the certificate age is tied to the time it might take some one to refactor a key
* Name doesn't match the cert > Can't trust that you communicating with the correct party, worth as much as plain text to me
* CA not trusted > Unless you can explicitly verity the end certificate and the chain = plain text to me
* Certificate is self-signed > same as the above
* Certificate was generated using old/broken crypto > depending on the exact issue government agencies will most likely be able to break the encryption, if it's more easy attacks like BEAST or CRIME so can resourceful non-governmental organizations and individuals.
This isn't just crying wolf we need a new and better system, one that ensures that the key exchange is secure, and one that ensures that who ever you speaking too is the actual intended precipitant and not a system which currently if one of those fails both fail, and more often than not can easily fail on both on it's own out of the gate.
It is exactly crying wolf because AFAIK, okay, cert expiration - you don't have to rekey when you go get a new one, you just get a new one. The benefit seems to be commercial, rather than technical.
Name doesn't match: I've encountered a legitimate (as opposed to an obvious misconfiguration) error along these lines precisely zero times in well over a decade.
CA untrusted: CA trust is worthless - the browser doesnt differentiate between "the person who holds the cert had control of the domain when we generated it" and "we made sure this person exists and checked their identity". (Unless you jump into the total scam that is EV certs...)
Would you kindly stop banging on about "As good as plain text?". because as has been explained to you ad nauseum, in the worst case it becomes you vs one attacker who holds the key to the bogus cert, instead of you vs anyone on the local wifi network. The number of attackers is unbounded in the latter case, QED, it is strictly a better security posture.
SSL as it exists today is fine for keeping a hacker out of your connection. It was not designed nor implemented for a post-Snowden world.
If sites start moving to HTTP/2, is it true the untrustworthy code can be inserted into the same stream as the "content"?
Everything could be coming from the same domain/IP? This might make blocking ads and tracking more complicated?
My solution as HTTPS spreads is to MITM my own connections so I can see what is being sent and received over the wire. As the article says, it is a PITA. But it is necessary.
There are just different problems. If everyone were to block ads, they'd become harder to block. And some of the websites that rely on them would stop existing.
I'm not sure I see how having ad traffic travel over HTTPS is a problem here. Malware researchers deal with HTTPS all the time. It's not some sort of insurmountable barrier -- the content is all available to a browser, after all.
The content is available after it is decrypted in a browser on a single host. If the streams are inspectable by network defenses they can be inspected at much more feasible scale allowing one device to protect 10,000s of hosts from the same malware-laden ad. The alternative is to try and deliver protection to 10,000 browsers, and somehow keep them synchronized which is just so much harder and expensive. Or you could make the host operating system, apps, and the browser resistant to exploitation...
It's not that encrypting secrets is bad (and sessions are secrets). It's that encrypting everything without looking at what you gain and lose is poor engineering and it all seems to be politicized somehow (camps, factions, dogma..) with HTTPS-only being pushed as the answer to one security problem (confidentiality vs active eavesdroppers) at the expense of existing solutions to other problems, including integrity (please don't compromise my hosts), availability (I cannot use recent browsers to admin my equipment because they ban self-signed certs but trust 100+ CAs) and non-repudiation (where did the malware come from?).
... speaking as someone who studies malware analysis.
22 comments
[ 5.3 ms ] story [ 61.3 ms ] threadAlso many of the malicious adds do not come from malware networks they come from all major ad networks including Google's.
You have ads exploiting zero day vulnerabilities in Flash and browsers that not easy to detect, and with the amount of syndication in ad networks you can't effectively blacklist or revoke them.
One of the downsides to this whole "letsencrypt" movement and CA's from less "organized" countries being accepted by major browsers and clients is that you will have much more failures in security.
SSL was designed around high level of trust and that trust worthy SSL certificates will not be easy to come by, this is why they used to cost so much there was actual inspection and you would get fraud insurance for quite high amounts. Today i won't be surprised if you could get a Google.com cert from some low tier CA in the Philippines which automates the process and it will be valid on large amount of devices.
We need a better verification system for SSL and actual policing of certificates including integrating it into DNS, if i ask for Google.com i should get a "cert" entry from the DNS server just as i get the A entry for it, and i don't understand why this isn't the case yet.
An attack against a self signed cert may cost more then what ever but that wasn't what we were talking about initially either.
If you can MITM which they can and can get cheap valid certificates it's game over.
And while the NSA might be able to get certificates no matter the case, people have managed to buy certificates for domains they do not own multiple times now.
Which puts the ability to MITM real world SSL sessions in the hands of individuals.
That ship sailed a long time ago. While hierarchical PKI has always been a flawed concept (I find it unlikely that you actually trust all of the organizations that firefox/etc ship as trusted roots). Even if you did, as you aid, these "authorities" have signed improper certs.
Trying to patch holes in this failed system (such as revoking those improper certs) is yet another foolish attempt to enumerate badness[1]. If you want authentication, you need do your own chain-of-trust instead of assuming ~100 cert authorities will do that for you.
> Which puts the ability to MITM real world SSL sessions in the hands of individuals.
So we should keep the world in plaintext (by not allowing self signed certs)?
Quite a few people besides the NSA already[2] MITM connections. My point is that we absolutely need to raise those costs. Even with the NSA, just because they have the capability to do something doesn't mean you should give up. Make the do the extra work of a MitM attck (even if probably a small amount of extra work in the case of the NSA).
Add another categorization if you want. Nobody said you have to treat self-signed certs as secure, just that they need to be used. Privacy from eavesdroppers and authentication are separate goals.
[1] http://www.ranum.com/security/computer_security/editorials/d...
[2] https://projectbullrun.org/surveillance/2015/video-2015.html...
I've said that we need to add additional levels of trust to the current PKI/SSL cert system preferably adding DNS records with the hash of the certificates and enforcing DNSSec globally this isn't the best solution but it's just enough of an easy hack that it will work for a good while.
What i do not want to see is people thinking that if we just spam SSL certs and stick them on everything it will some how help us, this is the classical definition of security theater.
When cost reduction isn't sufficient to thwart any effective surveillance, and worse using self signed certs trains people to just click accept, and free SSL certificates make it easier to gain valid certificates in a fraudulent manner things will only become worse not better.
While it's true that authentication and encryption are separate domains with how TLS/SSL is implemented currently they are tied by the hip, if you can't trust the authentication part of SSL the encryption part becomes meaningless to all but the most primitive types of passive sniffing.
If you want to separate them then lets kill TLS all together since PKI for the most part have failed, we can use other pure key exchange mechanism like well implemented DH without all the certificate nonsense.
Of course it's worth less; the point is that it's not worthless, and has greater value than plaintext.
> if the attacker can perform a MITM attack
Then you communication is still protected from other attackers.
> What i do not want to see is people thinking that if we just spam SSL certs and stick them on everything
That's exactly the thing that needs to happen. PHK was right when he pointed dout that it would be trivial for Apache to simply generate a self-signed cert on first use if no other cert exists, removing a lot of the plaintext on the the internet.
> it will some how help us
"some how"? The point was it provides very good protection against passive analytics (aka "eavesdropping", "spying").
> this is the classical definition of security theater.
Nonsense, nobody has ever claimed self-signed certificates were "safe", we only said they were better than plaintext. Why would you accept self-signed certificates as any kind of authentication?
> self signed certs trains people to just click accept
sigh
That dialog may be the biggest reason we're still using plaintext. I needs to die yesterday, for the very reason you say: it gives people bad habits. That kind of scary popup needs to be reserved for invalid certificates, which actually warrant that kind of attention. Given BULLRUN's large budget and how easy it is to manipulate software projects[1], it is somewhat suspicious that there just happens to be a scary popup if someone tries to encrypt without caring about authentication.
Nobody said anything about giving self-signed certificates any kind of trust. This is about removing plaintext. Unfortunately, there has been culture that badly confuses authentication with encryption (privacy) when they are entirely separate matters.
> meaningless to all but the most primitive types of passive sniffing.
Which is exactly the set of problems I'm talking about. Why do you want to continue allowing passive sniffing? We can trivially put a stop to this kind of nearly-free eavesdropping, but because those solutions don't address more complicated types of attacks (by design! use authentication when you can!), security people tend to be hostile to the idea. Meanwhile, as the search for a perfect solution continues, incredible amounts of passive sniffing is de facto accepted as the status quo.
[1] https://www.youtube.com/watch?v=fwcl17Q0bpk
I don't think that running plain text services is warranted, but i also do not want to see us rush into a horrible system that will not provide any sufficient protection against surveillance while forming the mindset of people into a false pretense of security. If we want security we should design a better system not force horrid implementation of already bad system.
What you are doing is like putting the people that we should moderate the use of antibiotics and anti-malaria drugs because of resistances in the same camps as anti-vaccine nut jobs. I want a better secure Internet, not one that is flooded with out of control certificates and poor implementations which will only make things worse and much harder to untangle in the long run.
And no self-signed certificates aren't better than plain text, unless i have received public key / thumbprint of the certificate through a channel I trust and could verify the sender of that information to me a self signed certificate is equivalent of plain text because the moment I have to accept that connection on good faith i cannot trust that the party which I am communicating it is the party I intended to communicate with or that no one else has the key.
Under those circumstances I will not transfer any information that I would not transfer over plain text period, if you do so well do it at your own peril.
So stop the fear mongering over self-signed certs so plaintext can simply end.
> while forming the mindset of people into a false pretense of security
Then stop conflating self-signed certificates with a trust system. I'm talking about a replacement for plaintext; this doesn't affect the handling of authenticated certificates in any way.
Since you still seem to not not understand this, let me be explicit: I'm saying we need protect against passive eavesdropping at the network level. I never said you should lie to the use* and claim their connection had any additional security. These fears about a "false pretense of security" are not relevant, as a move from plaintext to opportunistic encryption with self-signed certificates shouldn't be visible to the user.
> I cannot trust that the party which I am communicating it is the party I intended to communicate with or that no one else has the key.
Obviously. I never claimed otherwise. This isn't relevant, and if you want to protect against this threat model, you obviously need proper authentication (which I recommend whenever possible). Currently a lot communication on the internet has authentication risks AND allows anybody with a packet sniffer to log their data for next to no cost? You to believe it's a bad idea to convert those plaintext situations into something that has the same authentication risks while only betraying the contents to a single eavesdropper, who must be a MitM.
There is no technical reason not to do this. As you obviously know because you referenced the certificate warning popup, self-signed certificates are trivially identifiable, so there is no reason to confuse them with normal certificates. Absolutely nothing needs to change in how this is presented to the user, so we aren't creating any sort of false sense of security.
> Under those circumstances I will not transfer any information that I would not transfer over plain text period,
Good for you. What does that have to do with the fact that much of the internet is still filled with the plaintext of people who don't understand this kind of technical topic? Why are you resisting shielding their communications from passive eavesdropping?
This attitude that security must protect against all threats (or at least the treats YOU care about) is a major problem. What do you think is going to happen? It is magical thinking to assume that everyone will suddenly start using full, proper crypto (they can do that right now). We've been trying that for years and the result was a lot of people staying with plaintext.
This is a thing that happens right here, right now. We treat all of the following things as equivalent big scary warnings from the browser regardless of how bad they are or what the impact on security actually is.
Weve've got a couple decades of retraining to do because of this boneheaded, "wolf-crying" design.Name doesn't match: I've encountered a legitimate (as opposed to an obvious misconfiguration) error along these lines precisely zero times in well over a decade.
CA untrusted: CA trust is worthless - the browser doesnt differentiate between "the person who holds the cert had control of the domain when we generated it" and "we made sure this person exists and checked their identity". (Unless you jump into the total scam that is EV certs...)
Would you kindly stop banging on about "As good as plain text?". because as has been explained to you ad nauseum, in the worst case it becomes you vs one attacker who holds the key to the bogus cert, instead of you vs anyone on the local wifi network. The number of attackers is unbounded in the latter case, QED, it is strictly a better security posture.
SSL as it exists today is fine for keeping a hacker out of your connection. It was not designed nor implemented for a post-Snowden world.
Everything could be coming from the same domain/IP? This might make blocking ads and tracking more complicated?
My solution as HTTPS spreads is to MITM my own connections so I can see what is being sent and received over the wire. As the article says, it is a PITA. But it is necessary.
I'm not sure I see how having ad traffic travel over HTTPS is a problem here. Malware researchers deal with HTTPS all the time. It's not some sort of insurmountable barrier -- the content is all available to a browser, after all.
It's not that encrypting secrets is bad (and sessions are secrets). It's that encrypting everything without looking at what you gain and lose is poor engineering and it all seems to be politicized somehow (camps, factions, dogma..) with HTTPS-only being pushed as the answer to one security problem (confidentiality vs active eavesdroppers) at the expense of existing solutions to other problems, including integrity (please don't compromise my hosts), availability (I cannot use recent browsers to admin my equipment because they ban self-signed certs but trust 100+ CAs) and non-repudiation (where did the malware come from?).
... speaking as someone who studies malware analysis.
Cheers, adric