3 ms·

The ciphers are in order of preference. The blog post hinted at this (I'm not sure why it didn't make it the primary suggestion), but you may be able to get awa

The ciphers are in order of preference. The blog post hinted at this (I'm not sure why it didn't make it the primary suggestion), but you may be able to get away with simply duplicating a cipher. After reading the post, that's what I'm going to play with next time I run into this. I suspect duplicating will be fine in almost all environments, and by picking one way way down in the preference list to duplicate, I suspect you can increase the chances that there's nothing in the chain that will even have an opportunity to error based on the duplicated cipher preference. I tried this against the website quoted in the article and it worked without problem.

pimterry 5y ago
I'm the author - I didn't pick duplicates as the main suggestion partly because it's not clear if all TLS servers will accept that, but also because it's trivial for TLS fingerprinters to detect and defeat that automatically if they chose too. They just need to always strip subsequent duplicates from the cipher list before hashing, and the whole technique becomes useless. I doubt that's happening today, but I suspect it will very quickly if duplicate ciphers become commonplace. Actually reordering ciphers meanwhile definitively changes the hash, so there's nothing they can do in the general case at least, and there's a reasonably large number of acceptable non-duplicate orderings available to choose from. Duplicating ciphers is a good technique that's definitely worth investigating too, but it has its limitations, and it's not a silver bullet.
- PeterWhittaker 5y ago
  Re ECC and RSA: they rely on different classes of math problems, allowing for equivalent strengths with differing key sizes. ECC sizes are generally smaller, but that’s not the whole story, since some aspects of ECC allow for interesting attacks to which RSA, based on a much simpler problem, is not subject. See [1], e.g. In security, simplicity is often but not always by itself a win. Great article, btb, really appreciated the real world examples. 1: https://crypto.stackexchange.com/a/1194 https://crypto.stackexchange.com/a/1194

pimterry 5y ago

I'm the author - I didn't pick duplicates as the main suggestion partly because it's not clear if all TLS servers will accept that, but also because it's trivial for TLS fingerprinters to detect and defeat that automatically if they chose too. They just need to always strip subsequent duplicates from the cipher list before hashing, and the whole technique becomes useless. I doubt that's happening today, but I suspect it will very quickly if duplicate ciphers become commonplace. Actually reordering ciphers meanwhile definitively changes the hash, so there's nothing they can do in the general case at least, and there's a reasonably large number of acceptable non-duplicate orderings available to choose from. Duplicating ciphers is a good technique that's definitely worth investigating too, but it has its limitations, and it's not a silver bullet.

PeterWhittaker 5y ago
Re ECC and RSA: they rely on different classes of math problems, allowing for equivalent strengths with differing key sizes. ECC sizes are generally smaller, but that’s not the whole story, since some aspects of ECC allow for interesting attacks to which RSA, based on a much simpler problem, is not subject. See [1], e.g. In security, simplicity is often but not always by itself a win. Great article, btb, really appreciated the real world examples. 1: https://crypto.stackexchange.com/a/1194 https://crypto.stackexchange.com/a/1194