I'm wondering about this paragraph:<p>---
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.
---<p>Two points:<p>- 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.)<p>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: 7.4.7.1, 8.1.1)<p>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.)
"Because the TLS handshake occurs before the HTTP connection begins, there can be problems if there are multiple websites hosted on the same server, at the same IP address."<p>This is why Server Name Indication ( SNI ) is so important. It allows multiple host names on a single IP address to support HTTPS.<p>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 ).
Why don't they mention HSTS? Seriously a very important safeguard against HTTPS stripping.<p>Apart from that, my idea of what every web dev should know about HTTPS is <i>use HTTPS for everything</i>. The performance reduction is minimal and far less important than the security gain...
Good read about HTTPS, but very bad title. HTTPS does NOT stop attackers. It does stop data sniffing on wirelress network, but does not prevent any server-side attack (XSS, SQL Injection, an flaw in the web application).
I had quite low expectations for what I would learn from this article but it was actually very good. I really liked the paint analogy and the simplified understandable maths.<p>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?
Symmetric-key ciphers aren't used because they "save a round trip". They're used because they're much faster. One could use a public key encryption system to encrypt the entire session between two parties (e.g. RSA) but AES is <i>much</i> faster than RSA.
I like this article, and found his explanations surprisingly clear.<p>One nitpick: SSL doesn't really impose much bandwidth overhead. <a href="http://stackoverflow.com/questions/548029/how-much-overhead-does-ssl-impose" rel="nofollow">http://stackoverflow.com/questions/548029/how-much-overhead-...</a>
The article states that "Security breaks caching" but doesn't seem to give anything on the topic. Would a kind soukd elaborate or point me to tips on how to improve performance under these conditions ?
This article leads me to wonder. Has the US Government ever requested the master private keys for the main certificate authorities, such as Verisign?<p>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.<p>However, having the capability to impersonate any company, group, or individual has an enormous potential for abuse.
What about proxied MITM attacks using a valid CA certificate for the proxy? And also, browsers are not the only HTTP clients out there. HTTPS I believe is a quite a mess as is cert validation and the CA Cert system in general. I view HTTPS as security-lite. I think we need something better.