At this point, his browser would notice that the site was using a different certificate from the one it had always used in the past, and would pop up a big scary error message.
Why would the browser complain that the certificate has changed? Certificates change all the time, because they expire and have to be replaced. Usually they get replaced before they expire so there isn't any down time. Sometimes they get replaced because a private key is compromised. So under what circumstances, exactly, should a browser complain about a certificate changing?
There is exactly one attack that this stops: The attacker has hijacked DNS and the user is going directly to an https URL (probably through a bookmark).
And, as I say, I would estimate that this is a far more frequent attack than snooping. In practice, I regard this as a much more important threat to protect against than snooping, since, as I already said, smart web admins don't transmit secrets in the clear anyway.
In order to protect against this attack, Firefox is effectively restricting use of the https protocal to sites that have been centrally approved.
Your constant repetition of that claim doesn't make it true. There are several ways to use certificates that haven't been "centrally approved".
You're playing mighty fast and loose with the statistics. Where are you getting your numbers? I would lean toward hijacking being far more commonplace because DNS is so easy to subvert, and this can be done from anywhere without requiring direct access to the victim's network path. Meanwhile, the risk of snooping alone should be minimal, because smart site admins don't transmit secrets in the clear. And there's always Digest auth.
The truly commonplace problem is malware-installed keystroke loggers. Of course certificates of any stripe can't do anything about those.
As far as snoopers missing the beginning of a session, how common does your statistical oracle tell you it is that someone is able to snoop a session, but misses the beginning of it? Generally speaking, of course, anyone in a position to snoop on a connection is also in a position to hijack it. Eve and Mallory may have different names, but on the current Internet, Eve can almost always choose to be Mallory.
As far as protecting against the threats of snooping and hijacking, Firefox is protecting against both of those, which is superior to protecting against only one of them. I frankly don't understand the complaint, or, rather, I think it's vacuous. If you're using private certs for private sites, just import them into your cert db, or set up a private PKI for them. If you're creating public sites, shell out $15-$20 and get a real cert, and stop whining already.
A self-signed certificate is better than no certificate because it keeps out an attacker who can snoop but not hijack the connection. This is a common scenario, and worth protecting against.
Sounds pretty uncommon to me. What scenarios can you describe where an attacker is able to snoop but not hijack?
Why should self-signed certificates be treated any worse than no certificate?
Obviously, because when a user types "https:" in the location bar, or uses an https: bookmark, he or she expects an encrypted connection. There are multiple cues in the GUI for the nature of the connection you're using, and possibly the most important one is the URL scheme.
Honestly, buying an SSL certificate for a phishing site is like breaking into people's homes, stealing their TVs, and leaving a calling card with your full name and address in its place.
No, it's like leaving someone else's calling card. Or do you actually believe that phishers use their own credit cards to set up their scams?
I don't know of a $10 offering; if there's one from godaddy.com, I would pass, given my past experience with that company. But dynadot.com offers RapidSSL non-chained certs for $19.99 per year.
Isn't there some way we could serve certs from the zone file using DNSSEC?
There is a way we could have a superior PKI using DNSSEC, yes. (This should not be confused with the RFC describing a certificate record type for DNS; that simply provides an alternative way for publishing traditional X.509 certs.)
First, DNSSEC may be unworkable until the root is signed (which hopefully will occur later this year), and the important TLD registrars sign their TLDs and provide a way to publish signed DS records for subdomains. There are other strategies, but this would be the the most sound deployment of DNSSEC, from an architectural perspective.
When we have DNSSEC, then a modified version of SSL can be deployed in which domain owners publish public key(s) for each host in the domain. With DNSSEC, there is then a trust chain from the DNS root which validates the public key. There is no longer a general need for CAs in this scenario.
This is superior to the status quo for several reasons. First of all, the current method of acquiring a (non-EV) cert relies on insecure methods for verifying domain ownership, usually, by using clear text email to an address in the domain. This can be subverted by all of the same methods useful for attacking SSL and more, although it only happens once every year or two for each host. With DNSSEC, the analogous problem is getting your zone public key info signed (the DS record), but that only has to happen once every year or two for the entire domain. Once DNSSEC is set up for a domain, that domain can publish as many public keys as it likes, and doesn't have to pay for each one.
Another advantage of a DNSSEC PKI is that domain owners, unlike CAs, cannot sign public keys for hosts that are hierarchically unrelated. With the status quo, if you accept an enterprise CA cert, you implicitly trust that enterprise not to sign certs for other enterprises, because there is no domain constraint on CA certs.
Of course DNSSEC can be used for many other things as well, such as publishing SSH host keys, personal public keys, etc. With the latter ability, we can have mutual authentication and encryption, and effective public-key-based single sign-on.
Something like a CA is still useful in this scenario for doing what the EV certs do, namely asserting that a domain owner is the real enterprise you think it is. This is a completely different problem from distributing public keys, however, and only applies where there is a real enterprise you care about. For Bank of America, you want to know that bankofamerica.com actually represents that business. But for gmail.com, you don't care, because "gmail.com" is actually the identity of the business; we don't do other business with some company called "gmail".
Obviously, botted PCs are already compromised. All attacks are easy for those systems, including putting a keystroke logger on the system, subverting the browser, adding entries to a local hosts file (thus subverting the DNS), etc. You don't appear to understand the risks any better than the author of the article.
A self signed certificate is potentially more secure, since you haven't disclosed your private key to a third party...
Sigh. You don't disclose your private key to a third party when you request a certificate. You provide the public key, and the third party signs that with the private key corresponding to a CA certificate. Neither party reveals a private key to the other, or to anyone else.
I think the author makes Mozilla's case for them, by not appearing to understand the risks, especially at a time when DNS cache poisoning has become unusually feasible. E.g., the statement
Snooping a connection (i.e. on a wireless link) is much easier than any of the impersonation attacks that SSL authentication prevents.
is simply not true for clients of unpatched DNS servers. It's much easier for an attacker to get a remote user's traffic redirected to a host of his choosing than it is for him to snoop on that user's traffic. Volume-based attacks on DNS become increasingly easier as bandwidth increases, and people who operate botnets have a good chance of poisoning a cache even on patched nameservers, simply through brute force. Meanwhile, that smaller class of attackers who are in a position to actually snoop on traffic are also in a position to use an arp spoofing attack. Encryption is simply not useful without knowing whom you're encrypting to.
If you're feeling lucky, you can always add the exception. You can also sign your certs with a CA cert, and import that into your certificate database. Of course, anyone who trusts that CA cert also trusts you not to generate bogus certs for bankofamerica.com, etc... The solution to the problem is not to make the browser more trusting by default; it's to migrate away from X.509 to a PKI that allows domain owners to generate certs at no additional cost, such as a DNSSEC-based PKI.
You just keep making it more elaborate without actually solving the problem.
In your scenario, only sites that can afford to have multiple radically geographically disparate sites would be "secure", and that only after modifying the cert issuing process to take a full month, perform additional DNS-based tests (i.e. the CA system has to know how to bypass its recursive DNS servers and query all of the masters for the domain in question), ceasing any DNS changes for the full month (breaking DNS-based load-balancing in the process)... and after all that, you're still vulnerable to having plaintext email observed in transit.
I wonder how long a cert revocation takes in your absurd, baroque system.
This is vulnerable to subterfuge in all of the same ways that setting up an SSL connection is vulnerable, and more (e.g. compromise of an email account password).
This is vulnerable to subterfuge in all of the same ways that setting up a non-SSL connection is vulnerable, and more (e.g. compromise of an email account password).
The site has control of the security of their mailbox, based on what IP they point their domain MX record to.
You see, that's where you're wrong. Nothing guarantees the privacy of email. It may be observed by eavesdroppers (e.g. ISP staff or intruders) anywhere on the path from the CA to the MX, misrouted at layer 2 or 3, revealed through unauthorized access to the mailbox, etc.
If there had been a hijacking, it will be obvious days before the certificate is finally issued, let-alone released.
Huh? It's minutes from cert request to issuance. Have you ever bought a cert before?
It is completely secure, unless you have a realistic attack model that compromises it.
I've already given you several (e.g. attacker controls your upstream router, unauthorized access to mailbox, malicious ISP staff, etc.).
It doesn't matter how easy it is to get a domain: that's not what SSL is about. SSL assures that the domain name you intended to connect to is the one that you did connect to (validation), and provides privacy for that connection. The attacks SSL validation attempts to solve are those where the system you reached is not the one you specified, because of DNS subversion (e.g. cache poisoning), layer 2 or 3 subversion (e.g. arp spoofing, route hijacking), or other technique.
The specific piece of information that is used to validate the connection is the DNS name: SSL verifies that the subject of the certficate (the CN, i.e. common name) matches the DNS name used to initiate the connection. The methods for issuing certificates involve some third party (the CA) attempting to establish that the person requesting the certificate is in fact the person in control of this DNS name, usually by sending an email to an address in the domain, such as the registered domain contact. This is vulnerable to subterfuge in all of the same ways that setting up an SSL connection is vulnerable, and more (e.g. compromise of an email account password).
With DNSSEC, there is no need for a CA any longer. Once public keys are published in DNS securely, looking them up directly from DNS is just as secure as getting them from a cert, and the problem of establishing ownership of the domain no longer exists. (Or in fact, it is taken care of in the process of distributing the zone's key-signing key to the zone parent, which has to be done once anyway to set up DNSSEC in the first place.)
Once this is done, besides the ability to publish as many public keys in the DNS as you like at no additional charge (including host keys for SSH, keys for email addresses, etc), you have the additional benefit that no one can sign public keys for domain names outside their control. The status quo is defective because any CA can sign a cert for any subject. This is especially problematic where enterprises have their own PKI and CA. For example, a company may run a private CA and require employees to import the CA cert into their browser CA database so that company-issued certs can be validated. As a result, the company can forge certs for any name, so the company's CA operators can act as a MITM with any online transaction the employee conducts; not merely those involving company systems. There is no constraint provision in CA certificates for domain hierarchies, so once you trust a CA for one name, you trust it for every name.
In other words, the status quo is downright stupid. We need DNSSEC anyway to solve DNS cache poisoning; as connection speeds get faster, cache poisoning gets continually easier. So let's implement it already and migrate off of X.509 to something that works much better by integrating the certificates with the namespace they are supposed to be validated against.
All you really need do is validate the hostname ownership; however.
You do this by requiring a verifiable e-mail address at the domain.
Do you really seriously believe that plaintext email from an ISP to a domain account is secure? None of the measures you propose is even remotely secure; that you even propose any of those things is ridiculous. If someone controls your upstream router, what does any of those tactics prove to anyone?
The correct solution, as I've said elsewhere, is to couple the DNS with the public key distribution, by using DNSSEC and publishing public keys in the DNS. Without DNSSEC, DNS is insecure. With it, certificate authorities are useless middlemen, and create opportunity for subversion without providing any benefit whatsoever.
In other words, once we have a secure DNS--along with client software to pull public keys out of that, instead of using certificates signed by untrustworthy, costly, third parties--the CAs are obsolete. Naturally, companies like Verisign have been dragging their heels on DNSSEC because it leads to the demise of one of their big cash cows.
DNSSEC is the solution to a number of problems, and will lead to vastly improved security of the Internet by providing a verifiable, trustworthy, highly redundant, distributed, hierarchical database. Once we have that, we'll wonder how we ever got by without it, and why we tolerated the stupidity of the very concept of a CA for so long.
Sigh. The point of encryption is to hide what you are saying from some people, while revealing it to some other people. Do you really not understand that you can't do this if you don't know which people you're talking to?
The point of SSL is validation, then encryption. Without both, it's useless. And if you were paying attention to the noise about DNS cache poisoning last week, you should know that, without validation, SSL is truly useless.
... is to drop the fundamentally broken X.509 PKI infrastructure, where any CA can sign certs for any subject, and switch to a DNSSEC-based PKI where signing authority is limited to subdomains of the authority. In the process, we end up with the ability to sign all the certs you want, for every host, if you like, and have SSL anywhere.
There is simply no sense in which either HTML or HTTP can be said to be "based on" one another. They solve totally different problems, and neither is in any way dependent on the other. HTTP supports any content type by design. HTML supports any transport scheme by design. The only connections between the two are the existence of the MIME content type "text/html" and the URL transport schemes "http" and "https", and either technology operates correctly in the complete absence of these items. HTTP may have been in part motivated by HTML, but those of us old enough to remember Mosaic and the mishmash of ftp, gopher, wais, and various other transports, know that HTTP is not specifically designed to carry HTML—it is specifically designed to transport any document type.
Uh, no it isn't. Granted, a lot of the objects transported over HTTP are text/html, but a lot of them aren't. And you can put text/plain documents up on the web to your heart's content. Most people don't do this very often because with the textual part of the web, unlike with email, the point is to link to other things (hence the term "web"). Furthermore, you don't need HTML to link to other things in email because decent mail clients recognize links in plain text emails anyway.
Slashdot Mirror
You got it wrong.
plaintext = possibility of sniffing + possibility of unknown identity on the receiving end
self-signed https = possibility of sniffing + possibility of unknown identity on the receiving end + false perception of secure comms
Therefore, self-signed https is less secure than plaintext.
Why would the browser complain that the certificate has changed? Certificates change all the time, because they expire and have to be replaced. Usually they get replaced before they expire so there isn't any down time. Sometimes they get replaced because a private key is compromised. So under what circumstances, exactly, should a browser complain about a certificate changing?
And, as I said already, those people should shell out $15 for a cert already, and quit whining.
If you care, advocate for a better PKI, e.g. a DNSSEC-based PKI, where there won't be a charge for each certificate.
And, as I say, I would estimate that this is a far more frequent attack than snooping. In practice, I regard this as a much more important threat to protect against than snooping, since, as I already said, smart web admins don't transmit secrets in the clear anyway.
Your constant repetition of that claim doesn't make it true. There are several ways to use certificates that haven't been "centrally approved".
Yes, and the answer is, "Of course they did, because they're in the business of trading in stolen credentials. Duh."
You're playing mighty fast and loose with the statistics. Where are you getting your numbers? I would lean toward hijacking being far more commonplace because DNS is so easy to subvert, and this can be done from anywhere without requiring direct access to the victim's network path. Meanwhile, the risk of snooping alone should be minimal, because smart site admins don't transmit secrets in the clear. And there's always Digest auth.
The truly commonplace problem is malware-installed keystroke loggers. Of course certificates of any stripe can't do anything about those.
As far as snoopers missing the beginning of a session, how common does your statistical oracle tell you it is that someone is able to snoop a session, but misses the beginning of it? Generally speaking, of course, anyone in a position to snoop on a connection is also in a position to hijack it. Eve and Mallory may have different names, but on the current Internet, Eve can almost always choose to be Mallory.
As far as protecting against the threats of snooping and hijacking, Firefox is protecting against both of those, which is superior to protecting against only one of them. I frankly don't understand the complaint, or, rather, I think it's vacuous. If you're using private certs for private sites, just import them into your cert db, or set up a private PKI for them. If you're creating public sites, shell out $15-$20 and get a real cert, and stop whining already.
There's such a thing as colorblindness, you know. It's not uncommon.
Sounds pretty uncommon to me. What scenarios can you describe where an attacker is able to snoop but not hijack?
Obviously, because when a user types "https:" in the location bar, or uses an https: bookmark, he or she expects an encrypted connection. There are multiple cues in the GUI for the nature of the connection you're using, and possibly the most important one is the URL scheme.
No, it's like leaving someone else's calling card. Or do you actually believe that phishers use their own credit cards to set up their scams?
I don't know of a $10 offering; if there's one from godaddy.com, I would pass, given my past experience with that company. But dynadot.com offers RapidSSL non-chained certs for $19.99 per year.
There is a way we could have a superior PKI using DNSSEC, yes. (This should not be confused with the RFC describing a certificate record type for DNS; that simply provides an alternative way for publishing traditional X.509 certs.)
First, DNSSEC may be unworkable until the root is signed (which hopefully will occur later this year), and the important TLD registrars sign their TLDs and provide a way to publish signed DS records for subdomains. There are other strategies, but this would be the the most sound deployment of DNSSEC, from an architectural perspective.
When we have DNSSEC, then a modified version of SSL can be deployed in which domain owners publish public key(s) for each host in the domain. With DNSSEC, there is then a trust chain from the DNS root which validates the public key. There is no longer a general need for CAs in this scenario.
This is superior to the status quo for several reasons. First of all, the current method of acquiring a (non-EV) cert relies on insecure methods for verifying domain ownership, usually, by using clear text email to an address in the domain. This can be subverted by all of the same methods useful for attacking SSL and more, although it only happens once every year or two for each host. With DNSSEC, the analogous problem is getting your zone public key info signed (the DS record), but that only has to happen once every year or two for the entire domain. Once DNSSEC is set up for a domain, that domain can publish as many public keys as it likes, and doesn't have to pay for each one.
Another advantage of a DNSSEC PKI is that domain owners, unlike CAs, cannot sign public keys for hosts that are hierarchically unrelated. With the status quo, if you accept an enterprise CA cert, you implicitly trust that enterprise not to sign certs for other enterprises, because there is no domain constraint on CA certs.
Of course DNSSEC can be used for many other things as well, such as publishing SSH host keys, personal public keys, etc. With the latter ability, we can have mutual authentication and encryption, and effective public-key-based single sign-on.
Something like a CA is still useful in this scenario for doing what the EV certs do, namely asserting that a domain owner is the real enterprise you think it is. This is a completely different problem from distributing public keys, however, and only applies where there is a real enterprise you care about. For Bank of America, you want to know that bankofamerica.com actually represents that business. But for gmail.com, you don't care, because "gmail.com" is actually the identity of the business; we don't do other business with some company called "gmail".
Obviously, botted PCs are already compromised. All attacks are easy for those systems, including putting a keystroke logger on the system, subverting the browser, adding entries to a local hosts file (thus subverting the DNS), etc. You don't appear to understand the risks any better than the author of the article.
Sigh. You don't disclose your private key to a third party when you request a certificate. You provide the public key, and the third party signs that with the private key corresponding to a CA certificate. Neither party reveals a private key to the other, or to anyone else.
I think the author makes Mozilla's case for them, by not appearing to understand the risks, especially at a time when DNS cache poisoning has become unusually feasible. E.g., the statement
is simply not true for clients of unpatched DNS servers. It's much easier for an attacker to get a remote user's traffic redirected to a host of his choosing than it is for him to snoop on that user's traffic. Volume-based attacks on DNS become increasingly easier as bandwidth increases, and people who operate botnets have a good chance of poisoning a cache even on patched nameservers, simply through brute force. Meanwhile, that smaller class of attackers who are in a position to actually snoop on traffic are also in a position to use an arp spoofing attack. Encryption is simply not useful without knowing whom you're encrypting to.
If you're feeling lucky, you can always add the exception. You can also sign your certs with a CA cert, and import that into your certificate database. Of course, anyone who trusts that CA cert also trusts you not to generate bogus certs for bankofamerica.com, etc... The solution to the problem is not to make the browser more trusting by default; it's to migrate away from X.509 to a PKI that allows domain owners to generate certs at no additional cost, such as a DNSSEC-based PKI.
I think Mozilla has it 100% right.
You just keep making it more elaborate without actually solving the problem.
In your scenario, only sites that can afford to have multiple radically geographically disparate sites would be "secure", and that only after modifying the cert issuing process to take a full month, perform additional DNS-based tests (i.e. the CA system has to know how to bypass its recursive DNS servers and query all of the masters for the domain in question), ceasing any DNS changes for the full month (breaking DNS-based load-balancing in the process)... and after all that, you're still vulnerable to having plaintext email observed in transit.
I wonder how long a cert revocation takes in your absurd, baroque system.
Oops.
This is vulnerable to subterfuge in all of the same ways that setting up a non-SSL connection is vulnerable, and more (e.g. compromise of an email account password).
You see, that's where you're wrong. Nothing guarantees the privacy of email. It may be observed by eavesdroppers (e.g. ISP staff or intruders) anywhere on the path from the CA to the MX, misrouted at layer 2 or 3, revealed through unauthorized access to the mailbox, etc.
Huh? It's minutes from cert request to issuance. Have you ever bought a cert before?
I've already given you several (e.g. attacker controls your upstream router, unauthorized access to mailbox, malicious ISP staff, etc.).
It doesn't matter how easy it is to get a domain: that's not what SSL is about. SSL assures that the domain name you intended to connect to is the one that you did connect to (validation), and provides privacy for that connection. The attacks SSL validation attempts to solve are those where the system you reached is not the one you specified, because of DNS subversion (e.g. cache poisoning), layer 2 or 3 subversion (e.g. arp spoofing, route hijacking), or other technique.
The specific piece of information that is used to validate the connection is the DNS name: SSL verifies that the subject of the certficate (the CN, i.e. common name) matches the DNS name used to initiate the connection. The methods for issuing certificates involve some third party (the CA) attempting to establish that the person requesting the certificate is in fact the person in control of this DNS name, usually by sending an email to an address in the domain, such as the registered domain contact. This is vulnerable to subterfuge in all of the same ways that setting up an SSL connection is vulnerable, and more (e.g. compromise of an email account password).
With DNSSEC, there is no need for a CA any longer. Once public keys are published in DNS securely, looking them up directly from DNS is just as secure as getting them from a cert, and the problem of establishing ownership of the domain no longer exists. (Or in fact, it is taken care of in the process of distributing the zone's key-signing key to the zone parent, which has to be done once anyway to set up DNSSEC in the first place.)
Once this is done, besides the ability to publish as many public keys in the DNS as you like at no additional charge (including host keys for SSH, keys for email addresses, etc), you have the additional benefit that no one can sign public keys for domain names outside their control. The status quo is defective because any CA can sign a cert for any subject. This is especially problematic where enterprises have their own PKI and CA. For example, a company may run a private CA and require employees to import the CA cert into their browser CA database so that company-issued certs can be validated. As a result, the company can forge certs for any name, so the company's CA operators can act as a MITM with any online transaction the employee conducts; not merely those involving company systems. There is no constraint provision in CA certificates for domain hierarchies, so once you trust a CA for one name, you trust it for every name.
In other words, the status quo is downright stupid. We need DNSSEC anyway to solve DNS cache poisoning; as connection speeds get faster, cache poisoning gets continually easier. So let's implement it already and migrate off of X.509 to something that works much better by integrating the certificates with the namespace they are supposed to be validated against.
Do you really seriously believe that plaintext email from an ISP to a domain account is secure? None of the measures you propose is even remotely secure; that you even propose any of those things is ridiculous. If someone controls your upstream router, what does any of those tactics prove to anyone?
The correct solution, as I've said elsewhere, is to couple the DNS with the public key distribution, by using DNSSEC and publishing public keys in the DNS. Without DNSSEC, DNS is insecure. With it, certificate authorities are useless middlemen, and create opportunity for subversion without providing any benefit whatsoever.
In other words, once we have a secure DNS--along with client software to pull public keys out of that, instead of using certificates signed by untrustworthy, costly, third parties--the CAs are obsolete. Naturally, companies like Verisign have been dragging their heels on DNSSEC because it leads to the demise of one of their big cash cows.
DNSSEC is the solution to a number of problems, and will lead to vastly improved security of the Internet by providing a verifiable, trustworthy, highly redundant, distributed, hierarchical database. Once we have that, we'll wonder how we ever got by without it, and why we tolerated the stupidity of the very concept of a CA for so long.
Sigh. The point of encryption is to hide what you are saying from some people, while revealing it to some other people. Do you really not understand that you can't do this if you don't know which people you're talking to?
The point of SSL is validation, then encryption. Without both, it's useless. And if you were paying attention to the noise about DNS cache poisoning last week, you should know that, without validation, SSL is truly useless.
... is to drop the fundamentally broken X.509 PKI infrastructure, where any CA can sign certs for any subject, and switch to a DNSSEC-based PKI where signing authority is limited to subdomains of the authority. In the process, we end up with the ability to sign all the certs you want, for every host, if you like, and have SSL anywhere.
There is simply no sense in which either HTML or HTTP can be said to be "based on" one another. They solve totally different problems, and neither is in any way dependent on the other. HTTP supports any content type by design. HTML supports any transport scheme by design. The only connections between the two are the existence of the MIME content type "text/html" and the URL transport schemes "http" and "https", and either technology operates correctly in the complete absence of these items. HTTP may have been in part motivated by HTML, but those of us old enough to remember Mosaic and the mishmash of ftp, gopher, wais, and various other transports, know that HTTP is not specifically designed to carry HTML—it is specifically designed to transport any document type.
Uh, no it isn't. Granted, a lot of the objects transported over HTTP are text/html, but a lot of them aren't. And you can put text/plain documents up on the web to your heart's content. Most people don't do this very often because with the textual part of the web, unlike with email, the point is to link to other things (hence the term "web"). Furthermore, you don't need HTML to link to other things in email because decent mail clients recognize links in plain text emails anyway.
No, no, no. It goes to 11.