This public key exchange only needs to happen once per session, the first time the client and server connect. Once they’ve agreed on a shared secret, the client and server communicate using a symmetric-key crypto system which is much more efficient to communicate on since it saves an extra round-trip each exchange.
- The first and second sentences don't appear to be particularly related.
- The symmetric system isn't more efficient because of round-trips. (I'm also not sure which round trips it saves on.)
Also (and I made the same mistake in my talk...), yes, explaining DH is important, but now it kind of sounds like in TLS both sides figure out the master secret using DH (and, in your talk, specifically, regular DH, not EC-based DH), when in reality that depends on the ciphersuite, and the vast majority of TLS connections don't work that way. From what I understand to be most TLS configurations in the wild, the pre-master secret is encrypted using the server's public key. (RFC 5246: 126.96.36.199, 8.1.1)
Finally, a bit of a plug, but... If you're interested in the build up, my PyCon 2013 talk "Crypto 101" starts from XOR and ends with TLS in 45 minutes. It mostly goes into a bit more detail about thinks like block and stream ciphers. I'm hoping to eventually turn this into a book. (If you're interested, my e-mail's in my profile.)
Is there something in particular that you would like more of or perhaps to stay the same? Humor is good, I suppose?
Obviously, a book lets me go in more detail, but I'm disinclined to take that too far. The entire beauty of Crypto 101 is that it doesn't go into detail. Right now I'm mostly just marking sections that you could skip if you want to.
> In 2013, the Nokia's Xpress Browser was revealed to be decrypting HTTPS traffic on Nokia's proxy servers, giving the company clear text access to its customers' encrypted browser traffic. Nokia responded by saying that the content was not stored permanently, and that the company had organizational and technical measures to prevent access to private information
Apart from that, my idea of what every web dev should know about HTTPS is use HTTPS for everything. The performance reduction is minimal and far less important than the security gain...
You've got extra overhead to setup the connection, extra processing to handle the encryption, no intermediate caching AFAICT. Clearly that has some impact - I'd expect it to be significant.
> On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead.
> If you stop reading now you only need to remember one thing: SSL/TLS is not computationally expensive any more.
This is why Server Name Indication ( SNI ) is so important. It allows multiple host names on a single IP address to support HTTPS.
Once again, IE on Windows XP is the biggest problem here. Windows XP systems simply must use something besides Internet Explorer ( Chrome or Firefox would be good ).
It isn't just IE-in-XP though: there are a surprising number of people still using Android 2.x on the last generation or two of smartphones and IIRC SNI was only added to the stock Android browser in v4, so if your site is otherwise mobile friendly this is going to be a concern. If the overhead per certificate is a few Kb and that multi-domain cert needs to be as large as them all then 100s of names will mean several hundred Kb in the inital handshake which may be both slow and costly depending on the user's mobile network.
Though as has already been pointed out for a larger number: if you need to be using 100s of names and can't get hole of at least a few more IPv4 addresses to spread them around there is something either technically or financially wrong with your plans!
This is of course on of the reasons why we need IPv6, as this would become a complete non-issue. Unfortunately IPv6 support is going to be lacking a lot longer than SNI support is as ISPs would much rather mess with hacks like NAT and SNI instead of investing in upgrading the base network.
Does someone want to try it here? :P
Lets use root 2 and a small private number. We can do mod 10 (so the last digit of 2^(your secret) is your public number).
My public number would be 4. (My secret number is secret).
I know this is kind of goofy but it could be fun?
One nitpick: SSL doesn't really impose much bandwidth overhead. http://stackoverflow.com/questions/548029/how-much-overhead-...
It actually makes sense in a criminal investigation to spoof a real site in order to phish for passwords or the personal information of criminals. A similar method was used before to get cable thieves to call a phone number on the screen thinking they were giving their information to win a free item.
However, having the capability to impersonate any company, group, or individual has an enormous potential for abuse.
1. The client sends a CONNECT request (instead of GET) which instructs the proxy to open up a secure tunnel with the remote server. In this situation, the proxy steps out of the way and simply shuffles bits back and forth, as if it were just another router between networks.
2. Setup a "Man in the Middle Proxy" which creates/signs certificates for each site on the fly. Basically, the client thinks the proxy is the server, and the server thinks the proxy is the client. The only way this works though, is if the browser is instructed to trust certificates signed by the MitM proxy. So this works fine if you're setting up a proxy on your local dev machine, for example. But not for proxying HTTPS requests to actual users.
Proxying everything, including HTTPS traffic, is not uncommon for internal proxies at corporations.
Since they control the desktop infrastructure a lot of companies install an internal CA as trusted root. This trusted root can then masquerade as any website it wants since it can sign any certificate it generates on the fly. As a regular user you wouldn't even notice unless you are certificate pinning.
The other big use for internal CAs is being able to issue SSL certs for internal apps without having to have them signed externally (both the inconvenience and $$$ involved).