For a more secure handshake approach, consider the Diffie-Hellman key exchange, which is a way for two parties to agree on a secret number (a very large number when used for encryption, of course) that third party can't discover from looking at the network traffic. It's a very simple and intuitive algorithm; there's a great video that explains it here: https://www.youtube.com/watch?v=YEBfamv-_do Today, we generally use the ephemeral elliptic curve DH variant (ECDHE), which has better security characteristics and works much faster.
However, DH is not sufficient, you must also authenticate the other party. Otherwise you could be negotiating your key exchange with the attacker and not the real recipient. This is where public cryptography comes in. After the key exchange, both parties use their private keys to sign the transcripts of the entire conversation up until that point. When this is verified you know that (1) you're talking to the right person and (2) that you have a secret (session keys) that you can use to efficiently protect the conversation.
Disclosure: I am the author of Bulletproof SSL and TLS, already mentioned in another comment here. Feel free to ask me anything.
I think I'll buy my own copy today. :-)
I just noticed two days ago that my bank, for example, uses an RSA key exchange and I was kind of dismayed about the non-forward-secret sessions. But I don't know what I could tell them as a customer that would make them care about this problem. (I don't think my theoretical knowledge of why their key exchange method is bad will really help, compared to some kind of industry or governmental guidance that says "this technology is obsolete and everyone should stop using it", or, even better, "this technology is obsolete and banks should stop using it".)
Ultimately, I think the only way to kill the RSA key exchange is via a protocol revision, which is exactly what they've done in TLS 1.3. Sure, it will take a few years, but it will happen eventually.
I think banks like the RSA key exchange because it allows them to deploy transparent TLS traffic decryption via private key sharing.
It's amazing how strong a motivation a grade or ranking can sometimes be. We saw this a lot with EFF's privacy practices report
where companies were sometimes willing to make real changes to earn an extra star.
> I think banks like the RSA key exchange because it allows them to deploy transparent TLS traffic decryption via private key sharing.
Oh yeah, that was something they complained about a lot with mandatory PFS in the TLSWG. :-(
Why do they need this for their consumer-facing sites, though? The theory over in the working group was about monitoring activities of bank employees on third-party web sites (I thought), rather than about monitoring activities of bank customers on the bank's own web site.
I don't see how this proves anything as a MITM attack would be able to do this just fine. Perhaps you mean this is where the CA-Cert comes in as the client can then verify that the process has not be tampered as the attacker can not sign with the matching CA-cert?
But that's only where the chain of trust begins. As the next step, the client must now verify that the certificate had been issued by a CA they trust, and they do that by recursively verifying the signature of each issuer in the certificate chain (along a few other things) until they reach a CA that's trusted by default (because it's in the client's root store).
Just to complicate things further: TLS 1.2 and earlier support many key exchange options, which implement key agreement and authentication in potentially different ways. For example, some key exchanges don't use certificates but rely on pre-shared keys. Another example, in the RSA key exchange the server proves ownership of the private key by being able to successfully handshake, and so on. TLS 1.3 made some improvements in this area and the key exchange process has been streamlined. My point here is that there are many other details to take into account, but I am trying to keep my explanations at a higher level.
(1) Seems like the argument against RSA is "what happens when the server's private key is leaked?" But with ephemeral DH, it also requires private keys to be protected (now 2 of them!), these being signing keys. So isn't it simply trading one problem for another? Or perhaps the difference is that at least with DH, in theory only /new/ sessions can be attacked (MitM impersonating going forward), but older sessions can't be opened up.
(2) Doesn't this mean that now the client needs a keypair & certificate? Otherwise, how does the client sign? And where does the client key pair come from? I'm pretty sure my browsers (i.e., clients) don't have their own keys & certificates.
TIA for answering my silly questions.
Handshake integrity validation is always done, no matter which key exchange is used, and with effectively throw-away keys. So there's nothing there to protect long-term; those keys are going to disappear after the TLS session is complete.
The key difference with the RSA key exchange is that it forever leaves behind a piece of data encrypted with the private key (that can be recovered). Other key exchange methods use signatures, which have no value once the TLS session is complete.
(2) Public cryptography is not well suited for dealing with high volumes of data. Abstracting a little bit, handshake integrity is done via a HMAC, using keys that are negotiated for each session separately. Once the session is complete, these keys also disappear.
To drill deeper in the the handshake, however, both client and server do sign the initial handshake (with the final negotiated session secret, effectively). The idea is that you need to ensure that the handshake hasn't been tampered with. An active network attacker could have changed the original TLS connection request (ClientHello) to force usage of a particular cryptographic component they know how to break. For example, SSL v2 had no handshake protection which is why someone in control of the network could always enforce the weakest encryption (only 40 bits).
One important point I would make is that my book doesn't dissect the protocols in detail. There is only one chapter (about 50 pages) dedicated to the protocol and I wanted to cover it at a level that virtually everyone will want to understand. If you want more than that, hundreds of pages won't be enough; in the end you will have to dive into the dozens of RFCs, and so on. What I do do, is point to those RFCs so that you at least know where to find the additional documentation. IIRC there are more than 600 links in the book and they can all be found here (automatically extracted from the DocBook XML manuscript): https://fsty.uk/bulletproof-ssl-and-tls
My realisation was that, in practice, actual protocol flaws are not the weakest link. Instead, there are hundreds of different problems everywhere in the ecosystem, so you need to look at the issues in the protocol, but also in the certification authorities and the certificate issuance process, SSL/TLS stacks, clients, browsers, servers, libraries, development and configuration practices, and so on. My book is thus very practical and examines all these aspects that you need to understand at at least some level if you want to use TLS.
BTW, please note that I will send you a free digital copy of the book if you buy the paperback _anywhere_ and send me the receipt. The benefit of the digital edition is that it's typically much more current than the paperback. In fact, the digital edition is fully up to date at the moment. I published a complete revision just yesterday.
In TLS 1.3, the full handshake is one RTT without any tricks; resumption also. There is also a 0-RTT resumption, but it sacrifices security for speed. Lots of people are unhappy about it.
If you do want to eavesdrop, you have several options. For one, you can terminate the TLS traffic, access it, then create another entirely separate TLS session to send it elsewhere. This is easier with a reverse proxy, in which case the proxy is the server. If you want to transparently intercept client-initiated sessions you have to install your root CA key in each client device.
Going back to servers, another option is private RSA key sharing, which allows for passive decryption, but works only with the RSA key exchange. Finally, you can also play with session ticket keys. If you share those, and enable session tickets, you'll also be able to passively decrypt. This last option works even with DHE/ECDHE key exchanges.
- Implementing SSL / TLS Using Cryptography and PKI 
- Bulletproof SSL and TLS: Understanding and Deploying SSL/TLS and PKI to Secure Servers and Web Applications 
In the first one the author implements the protocol (RSA/DH) from scratch (without even using any crypto library). The second one is a classic and contains a lot of interesting scripts (the chapter on using OpenSSL and creating your own PKI is available for free: https://www.feistyduck.com/books/openssl-cookbook/).
I spent some time studying TLS and wrote two blog posts , in which I decrypt the network traces of the TLS sessions. Maybe someone will find them interesting too.
What you can't do is read a book or two about cryptography, the way you would a new programming language, and then bootstrap your own expertise from that. Cryptography is a lot trickier than most other topics in computer science.
Is that actually true? Or is it that most software development isn't really about topics in computer science. Like if you wanted to design your own distributed database wouldn't most of what you said above also apply?
Isn't this really a case where "hard topic is hard"?
Obviously, don't make your own block cipher, either.
http2 helps because you can multiplex a bunch of requests into a single connection, less waiting on new connections to be established.
TLS 1.2 with session resumption lets clients reuse existing sessions after the first connection.
TLS 1.3 has a 0rtt handshake, which is pretty baller. It's just not widely deployed.
TLS 1.3 has a 0rtt handshake, which is pretty baller.
It's just not widely deployed.
Also 0RTT is only for re-connections not initial connections.
The solution is only like 0RTT be executed once and only once, but this isn't part of TLSv1.3 and is waiting to _globally_ approved. Until then nobody smart will touch it.
0RTT is only supported by Cloud-Flare and Google. Cloud-Flare makes you track 0RTT yourself so a fair number of sites are insecure. Google does SSL tick synchronization across data centers because their arrogant and is extremely vulnerable to timing att-
Granted I suppose such interpretation would have to be done by browsers.
And even then it could be used to figure out which site you are visiting.
* The TLS connection is instantly closed after the GET ends
* A new 0RTT ticket isn't created
* No session information is transmitted (most GET's even have session information for ads/metrics).
What is a "global load balancer"? A load balancer doesn't avoid any round trips. The "work" of TLS begins as soon as the client sends a ClientHello which is during the second round trip. On a new connection the total round trips is 4 if you include the GET request. It's 3 round trips if you only consider the TCP hand shake and the TLS handshake. This is true whether there is a load balancer or not.
Think CloudFlare CDN or the Google Cloud Load Balancer.
Edit Mistyped RTT as TTL.
>"There are some really cool "tricks" for avoiding the round trip — round trips are why everyone should be using a global load balancer for SSL."
"Avoiding" means not incurring them, so yes they did claim a "global" LB would eliminate round trips.
The simpler sentence is: minimize round trip cost by getting close to users. Also avoid round trips if you can. :)
Here's a good guide to an SSL handshake: https://www.incapsula.com/cdn-guide/cdn-and-ssl-tls.html#ssl...
The handshake adds 2+ additional round trips, so a CDN can definitely help this.
Without PFS if the server's private key was stolen (e.g. by hacking the server) then all traffic sniffed in the past could be decrypted.
If the browser's symmetric key is encrypted with icicibank's public key, why can't a sniffer unlock it by also requesting icicibank's public key and decrypting the key sharing message?
- stuff encrypted with the private key can only be decrypted using the public key.
- stuff encrypted with the public key can only be decrypted using the private key.
This is why the public key can be distributed around freely and anyone can use it to encrypt, because only the person with the private key can decrypt it (and this is why you really need to keep your private key secure!)
The flip side is anyone can decrypt something encrypted with the private key (since the public key is widely known). But this is how we can verify that the other server really is who they say they are - remember that the public key can only decrypt stuff encrypted with the private key, so if we can decrypt something from the server then we know that they encrypted it using the private key and are therefore probably legit (...or the private key got leaked or CIA/Snowdon etc)
Enjoy learning! :)
This however is a decent resource for learning the things you're asking about such as public key crypto, asymetric vs symetric, digital signatures, etc. Specifically weeks 5 and 6. The whole course is good though.
For Diffie-Helman key exchange, atleast...
Encrypting/"locking" uses the public key.
Unlocking a public-key-encrypted-symmetric-key happens with icicibank's private key, which the sniffer does not have.
Here's another diagram:
Asymmetric key exchange for secure session setup / authentication
Symmetric key for secure session data encryption
Anyone can encryption (put things in), but only the Private Key (the bankers) can decrypt (see whats inside).
Also note the delay created by each step in (3).
Browsers solve this problem by bundling a number of trusted root certificates. (This is what they mean by "my trusted keys".)
When you connect to some web site, the server sends you their certificate along with a chain of signing certificates up to some root of trust. Assuming the root certificate is among those your browser trusts, you can verify the signature chain and establish a trusted connection.
See also: https://gist.github.com/coolaj86/e07d42f5961c68fc1fc8 ("Please petition Github to support HTTPS on github pages") and comments
Found this on this site, parallax.js wedding invitation. This is cool, how hard is it to learn how to do this?
p.s. In this example they are changing margins and top/bottom/left/right positions, which is not really a good way to do it, a better way to it is using transform: translate(), it's less resource intensive and especially when you use translate3d. You can read more about the performance difference between using top/left/bottom/right and translate() : https://www.paulirish.com/2012/why-moving-elements-with-tran...