but well it was said about longer keys (okay outside the quote) but apple systems cant even deal with keys longer than 4k.
I’ve seen that often enough when I ssltest’ed some of my stuff with long keys.
Yeah, such incompatibilities can of course also cause problems. That's why offering ECDHE is a very good idea.
but I thought for the start "WTF, why cant apple support longer keys"
4k may hold a while but let’s not forget Moore’s law or whatever it was called.
I dod an overkill for one of my sites with a 16k key but then again if you want to lock out apple people this is a really intresting measure, especially because it works better than useragents and stuff because they cant be spoofed
Interesting idea... 
It was a reply to My1, not to you.
The NSA is saying one EC is acceptable, but generally to stick to longer DH/RSA keys while we await quantum-resistant algorithms. Their rationale for saying to stick with “legacy” PKI stinks rather, and to be honest I think it may have something to do with the potential breakability of most ECC by nation states. I have no proof of this, but they’re hardly going to shout it from the rooftops if it were the case.
And as far as quantum decryption is concerned, it would take a few more years to break 4096 bit DH/RSA than any of the current EC algorithms, apparently (depending on how quickly it develops) meaning that they would have somewhat longer-term resistance than EC implementations.
So I was partially wrong, they’ve deprecated them in Chrome 50, so it doesn’t present them in the initial handshake, but does fallback to DHE suites if that’s all the server supports.
The developer console does say they’ll be removed entirely in Chrome 52.
Mozilla are planning the same, but there hasn’t been much activity on the bug report.
Okay, thanks for the links.
I think a big reason for depreciating DHE is Logjam as many websites still use insecure DHE params. According to SSLPuls ~25% of the webservers still use 1024bit there.
why not just deprecate only those who are affected
the unsecure DHE params are known and 1024 can be see easily enough as well
According to the numbers Google saw, only ~2% of connections ended up using DHE, and of those ~95% were 1024-bit.
Since there’s apparently issues trying to deploy 2048 bit or higher DHE (The RFC they link goes into detail), it’s easier to just move everybody to ECDHE (And eventually something like SIDH/RLWE-KEX, assuming they’re secure) than try to get server operators to update.
Edit: And of course after saying this I find that it’s changing as part of TLS 1.3, so it could come back?
What issues are there deploying 2048 bit or higher DHE? I didn’t have any problems deploying 4096 bit DHE.
From what I understand, the way TLS 1.2 and lower use DHE is an either/or affair. Either the client accepts the DHE key the server offers, or it doesn’t use DHE at all (Similar to how RSA works), if the client doesn’t support the bit length of the cert, it can’t negotiate something lower (And the server can’t know the limitations of the client)
Leads to issues where if the client only accepts weak keys (512/1024 bits) then the server can’t skip DHE, it will offer something the client doesn’t support, and if the server only offers a weak key then the client can’t ask for anything higher, it’ll just skip DHE.
In the process of overhauling everything in TLS 1.3, they’ve changed DHE to be negotiated through the same mechanism that EC stuff is currently. Instead of each server operator needing to generate their own dhparams file and what not, they’ve provided a list of fixed DHE groups that browsers need to support, and they can pick which ones to announce (And then the TLS server picks the one from that list what it wants to use).
Since it’s now properly negotiated, it can be improved upon in the future without causing incompatibilities (Since if the client only announces DHE groups the server doesn’t know, it can actually see that and not try to use it, instead of trying and failing). Of course ECDHE is still a better option (Unless you’re facing an attacker with a quantum computer), but at least they’ve fixed this deficiency.
Thanks. I guess that would explain the huge swathe of older clients that don’t work with my server in ssllabs.
I guess that depends on the EC used. As I've already stated, the US Govt is mandating either 3k or higher DH/RSA or ECDH with NIST P-384 for key establishment for any Top Secret stuff. Any other EC is verboten. And this isn't for post-quantum encryption, but for now prior to creation of a post-quantum encryption suite https://penfold.fr/docs/CNSA-Suite-and-Quantum-Computing-FAQ.pdf
How do I migrate from a pinned non-Letsencrypt cert to a pinned Letsencrypt one?
You have a few choices depending on what you currently have pinned, which client is used and how, and which level you want to pin at.
If you want the client to generate the keys like certbot does by default then you should add DST Root CA X3 and ISRG Root X1 to the pin set and wait the current max-age before changing.
If you want the client to use an existing CSR or key and currently pin the leaf certs then you can keep things as they are. If you currently pin at the CA level add the two pins named above, however you can skip the waiting period by using your pinned backup leaf.
1 Like
So you suggest pinning the root CA, that way I wouldn’t have to re-pin each newly-generated leaf cert when they expire? Why wouldn’t pinning the chain (as done in the OP above) accomplish the same thing?
Isn’t it more secure to pin the leaf cert only?
It’s a case of balancing the risk of mis-issuance against the risk of all pinned certs becoming unusable.
While pinning leaf certs is more secure in the sense of preventing mis-issuance, it’s risky in the sense of accidentally locking yourself out. This could happen if the backups are destroyed or compromised.
Pinning the intermediate is also risky as CAs can swap them out at short notice, note that while the X1 and X3 intermediates are the same key they could have been different. In contrast a replacement root would have to go through the long inclusion processes of the various browsers and OSs.
Ultimately while pinning roots has lower protection against mis-issuance compared to pinning leafs, it’s still a huge improvement over allowing any CA to be used.
1 Like
[quote=“cool110, post:96, topic:2436”]
add DST Root CA X3 and ISRG Root X1
[/quote]Why not just DST Root CA X3? What’s ISRG Root X1? Another CA that issues for Let’s Encrypt?
Just to verify, the hash of DST Root CA X3 is: Vjs8r4z+80wjNcr1YKepWQboSIRi63WsWXhIMN+eWys=
and that of ISRG Root X1 is: C5+lpZ7tcVwmwQIMcRtPbsQtWLABXhQzejna0wHFr8M=
correct?
ISRG is the corporation that runs LE. Their root has recently passed Mozilla’s inclusion process and is going through the others. Once Firefox 50 is released it’s possible for a chain to be built to that root ignoring DST Root CA X3, therefore both should be pinned.
Both of those hashes are correct.
1 Like
[quote=“Alives, post:1, topic:2436”]
SSLOpenSSLConfCmd DHParameters “/etc/ssl/private/dhparams_4096.pem”
[/quote]Doing this didn’t bump my key-exchange score up to 100%. I wonder why.