HTTPS and Security Certificates
Apr. 7th, 2011 04:10 pmSo, as I understand it, if you're connecting to a website with a browser, there are several ways someone may spy on your data.
1. If you trust everyone with physical access to your computer, everyone on your local network, your ISP, and every company and country inbetween your ISP and the DNS server and between your ISP and the webserver for the website, then there's no obvious way for anyone to spy on or tamper with your connection. (Analogy: you put it in the post, and trust the post office. If you put it in the "out" tray at work, you trust whoever posts it.)
2. If you don't trust all those (which you probably shouldn't, unless you're on an unsecured or WEP-encrypted wireless, in which case you definitely shouldn't trust them, because just anyone could sit down next to you and use a simple program to see your internet traffic as easily as their own), you should encrypt all the data sent between you and the website. Assuming the encryption is done right (eg. by a widely approved protocol, and all your operating system/browser updates have been installed)., no-one between you and the other end of the connection can see (or alter) the data sent.
3. However, that only applies to an existing connection. If you form a new connection between your browser, and, say, gmail.com, a motivated spy sitting on your unsecured wireless network can get their computer to send a web page that looks identical (even in terms of what packets are sent) to one that should be sent by the real gmail. At which point, no-one else can tamper, but all your sensitive data is going straight to the nasty guy/gal. (Obviously it's more complicated than that, according to exactly which packets go where, but the point is, they will probably be able to interfere in some way, and ANY way is bad.)
When people talk about security, this is the sort of thing they mean.
Part of the solution to the last problem is that with public key/private key cryptography, it's easy for your computer to tell that the person encrypting the other end of the connection is the one who provided a public key earlier (which is just a file containing a long string of numbers used to encrypt stuff).
For instance, if you've connected to the same website before, and it's using the same keys, your browser can tell if it's the same website. And if it isn't it can ring all sorts of bells and flash red and send a warning message, because if the computing puporting to be "gmail.com" is different to the ones puporting to be "gmail.com" last week, there's a chance it's Jo Hacker's computer. (Although that's not exactly what happens in real life, as we'll find out.)
Or for instance, if there's some way to ensure that the computer providing a website puportedly from "gmail.com" is the same one owned by the large and unmissable google corporation?
The last is the method which has historically been adopted. The big corporation provides (physically, in person, or some other safe way) to mozilla or whoever the public half of their key, which is shipped as part of firefox. So as long as your original firefox is ok (and if it isn't you're screwed anyway because you're running unsafe code on your home computer and typing your passwords into it, and for all you know it's emailing them straight to some Sealand hacker), it can tell that the computer it connects to is run by the same people as ran the original big corporation, which is what you wanted.
However, in fact, everyone who runs a website can't do this, because there's too many people. So what happens is there's a dozen big corps who everyone knows who they are (like Verisign) whose certificates are shipped in the browser, and they do the bit where some lesser corp satisfies them they're real-life people, not some internet scam, and then they (using the same sort of maths) provide them with a certificate that says "thisdomain.com is ok by us".
By OK (as far as I can tell), it means (a) it belongs to some company who are not obviously outright criminal and (b) the domain chosen is not horribly misleading. So verisign would only let google get a certificate for "gmail.com" but anyone not actively criminal could get a certificate for some new website called halfwaybananas.com (?)
And your browser represents this by (in the old days) the presence or absence of a little padlock icon or (nowadays) GIANT RED FLASHING TEXT if something seems wrong.
So, this is the way it is. And it provides security against casual hackers, the same way a determined attacker could steal your post (by dressing up as the post-man, or prying open a pillarbox or whatever) but (unless you leave it in the out-tray) they can't easily just glance at it because they're curious.
But many people who know about it are concerned because the system tries to pretend it's secure, but actually has all sorts of holes people can exploit if they happen to put the effort in. For instance:
1. Verisign and other similar companies are supposed to do the casual vetting that people applying for certificates are not obviously criminal. However, they'd obviously get a lot more money if, instead of actually checking, they simply charge a big fee and assume anyone willing to pay it is mostly legit. And so there is a great temptation to do so.
2. And they also resell the ability to sign certificates to smaller certificate signing authorities, and so on, and it turns out that when there are enough muppets with good intensions, 2 pence, and a paper clip trying to run a certificate signing authority, eventually one of them will get hacked. This happened recently, when some Iranian guy/gal hacked Comodo and signed several certificates for major websites (gmail, yahoo, etc). That only does anything for a hacker who can as previously described get onto the same network as a victim and do the "pretend to be the real website thing", but as previously described, that's not that hard to do, and if they do, the fact that people are connecting over an encrypted connection will make them less likely to suspect a problem.
3. There are all sorts of small technical problems which go unfixed. For instance, there's supposed to be a way for certificates to be revoked, but it's easy for a hacker to circumvent this.
4. The big trouble with the current model is that it's too big. It tries to cover millions of websites and condense everything down to "safe" or "not safe". And most people, including most users, and many, many people runing websites and (I am not making this up) many people running certificate signing authorities, don't really understand how it's supposed to work. And no-one involved has much of an incentive to fix it, rather than just shuffling the blame off on someone else (as it works _most_ of the time). It would probably be better if instead of trying to divide, in advance, which certificates are trustworthy, the main focus is on your browser reporting "this is the same website you connected to last time" or "despite having the same URL, this website may be produced by a completely different computer". And then most of the time, all is fine, and the excessive effort can be devoted to solving the reduced problem of "how can I trust a website the first time I connect to it?" and if the website changes its certificate without warning people (and certifying the change with the previous certificate) on the day you log in from a starbucks open wireless connection, you can be rightly suspicious, rather than having false alarms every time some website does something a bit wrong.
[This was based on an excellent article summarising an even better slide presentation, that was both more accurate and funnier than my post, but I can't see the link now, I think it was from dotaturls, does anyone have a link?]
So, that's obviously not complete, but is it about right?
1. If you trust everyone with physical access to your computer, everyone on your local network, your ISP, and every company and country inbetween your ISP and the DNS server and between your ISP and the webserver for the website, then there's no obvious way for anyone to spy on or tamper with your connection. (Analogy: you put it in the post, and trust the post office. If you put it in the "out" tray at work, you trust whoever posts it.)
2. If you don't trust all those (which you probably shouldn't, unless you're on an unsecured or WEP-encrypted wireless, in which case you definitely shouldn't trust them, because just anyone could sit down next to you and use a simple program to see your internet traffic as easily as their own), you should encrypt all the data sent between you and the website. Assuming the encryption is done right (eg. by a widely approved protocol, and all your operating system/browser updates have been installed)., no-one between you and the other end of the connection can see (or alter) the data sent.
3. However, that only applies to an existing connection. If you form a new connection between your browser, and, say, gmail.com, a motivated spy sitting on your unsecured wireless network can get their computer to send a web page that looks identical (even in terms of what packets are sent) to one that should be sent by the real gmail. At which point, no-one else can tamper, but all your sensitive data is going straight to the nasty guy/gal. (Obviously it's more complicated than that, according to exactly which packets go where, but the point is, they will probably be able to interfere in some way, and ANY way is bad.)
When people talk about security, this is the sort of thing they mean.
Part of the solution to the last problem is that with public key/private key cryptography, it's easy for your computer to tell that the person encrypting the other end of the connection is the one who provided a public key earlier (which is just a file containing a long string of numbers used to encrypt stuff).
For instance, if you've connected to the same website before, and it's using the same keys, your browser can tell if it's the same website. And if it isn't it can ring all sorts of bells and flash red and send a warning message, because if the computing puporting to be "gmail.com" is different to the ones puporting to be "gmail.com" last week, there's a chance it's Jo Hacker's computer. (Although that's not exactly what happens in real life, as we'll find out.)
Or for instance, if there's some way to ensure that the computer providing a website puportedly from "gmail.com" is the same one owned by the large and unmissable google corporation?
The last is the method which has historically been adopted. The big corporation provides (physically, in person, or some other safe way) to mozilla or whoever the public half of their key, which is shipped as part of firefox. So as long as your original firefox is ok (and if it isn't you're screwed anyway because you're running unsafe code on your home computer and typing your passwords into it, and for all you know it's emailing them straight to some Sealand hacker), it can tell that the computer it connects to is run by the same people as ran the original big corporation, which is what you wanted.
However, in fact, everyone who runs a website can't do this, because there's too many people. So what happens is there's a dozen big corps who everyone knows who they are (like Verisign) whose certificates are shipped in the browser, and they do the bit where some lesser corp satisfies them they're real-life people, not some internet scam, and then they (using the same sort of maths) provide them with a certificate that says "thisdomain.com is ok by us".
By OK (as far as I can tell), it means (a) it belongs to some company who are not obviously outright criminal and (b) the domain chosen is not horribly misleading. So verisign would only let google get a certificate for "gmail.com" but anyone not actively criminal could get a certificate for some new website called halfwaybananas.com (?)
And your browser represents this by (in the old days) the presence or absence of a little padlock icon or (nowadays) GIANT RED FLASHING TEXT if something seems wrong.
So, this is the way it is. And it provides security against casual hackers, the same way a determined attacker could steal your post (by dressing up as the post-man, or prying open a pillarbox or whatever) but (unless you leave it in the out-tray) they can't easily just glance at it because they're curious.
But many people who know about it are concerned because the system tries to pretend it's secure, but actually has all sorts of holes people can exploit if they happen to put the effort in. For instance:
1. Verisign and other similar companies are supposed to do the casual vetting that people applying for certificates are not obviously criminal. However, they'd obviously get a lot more money if, instead of actually checking, they simply charge a big fee and assume anyone willing to pay it is mostly legit. And so there is a great temptation to do so.
2. And they also resell the ability to sign certificates to smaller certificate signing authorities, and so on, and it turns out that when there are enough muppets with good intensions, 2 pence, and a paper clip trying to run a certificate signing authority, eventually one of them will get hacked. This happened recently, when some Iranian guy/gal hacked Comodo and signed several certificates for major websites (gmail, yahoo, etc). That only does anything for a hacker who can as previously described get onto the same network as a victim and do the "pretend to be the real website thing", but as previously described, that's not that hard to do, and if they do, the fact that people are connecting over an encrypted connection will make them less likely to suspect a problem.
3. There are all sorts of small technical problems which go unfixed. For instance, there's supposed to be a way for certificates to be revoked, but it's easy for a hacker to circumvent this.
4. The big trouble with the current model is that it's too big. It tries to cover millions of websites and condense everything down to "safe" or "not safe". And most people, including most users, and many, many people runing websites and (I am not making this up) many people running certificate signing authorities, don't really understand how it's supposed to work. And no-one involved has much of an incentive to fix it, rather than just shuffling the blame off on someone else (as it works _most_ of the time). It would probably be better if instead of trying to divide, in advance, which certificates are trustworthy, the main focus is on your browser reporting "this is the same website you connected to last time" or "despite having the same URL, this website may be produced by a completely different computer". And then most of the time, all is fine, and the excessive effort can be devoted to solving the reduced problem of "how can I trust a website the first time I connect to it?" and if the website changes its certificate without warning people (and certifying the change with the previous certificate) on the day you log in from a starbucks open wireless connection, you can be rightly suspicious, rather than having false alarms every time some website does something a bit wrong.
[This was based on an excellent article summarising an even better slide presentation, that was both more accurate and funnier than my post, but I can't see the link now, I think it was from dotaturls, does anyone have a link?]
So, that's obviously not complete, but is it about right?