11–20 of 45 posts
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. 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 goo…
"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." 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 Inte…
GlobalSign has a pretty brilliant solution for dealing with Windows XP -- https://www.globalsign.com/cloud/multiple-ssl-certificates-s...
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.
This is pretty much what I was trying to see if we could do: proxy HTTPS requests to another site through our server. When proxies are involved with HTTPS, there are really two options: 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 we…
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).
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).
Earlier quoted context omitted.
GlobalSign has a pretty brilliant solution for dealing with Windows XP -- https://www.globalsign.com/cloud/multiple-ssl-certificates-s...
The fallback is "multi-domain certificate", which means, if you host 10K domains, your server will send a certificate which contains 10K certificates within (a very large chunk), before anything can start. This solution is not scaleable obviously.
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 much faster than RSA.
Earlier quoted context omitted.
GlobalSign has a pretty brilliant solution for dealing with Windows XP -- https://www.globalsign.com/cloud/multiple-ssl-certificates-s...
The fallback is "multi-domain certificate", which means, if you host 10K domains, your server will send a certificate which contains 10K certificates within (a very large chunk), before anything can start. This solution is not scaleable obviously.
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.
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 much faster than RSA.
Speed is one concern but far from the main reason. You couldn't use a typical-length RSA key to encrypt a large chunk of data because there's a max input size for any given RSA key size. Standard block/stream cipher modes of operation are defined only for symmetric key ciphers.
--- 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. ---
Two points:
- 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: 7.4.7.1, 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.)