I wanted to know why the SSL I’m using for websire is using an old key exchange? It’s using RSA with an AES_128. Is there a way I could get a stronger key?
Hi Abdul,
This is a property of the ciphersuite negotiated during a HTTPS connection to your server. What HTTP server are you using (Apache, Nginx, other?). Can you share the configuration?
Your certificate is fine in this case and the problem lies with your webserver configuration.
Hi there,
Thanks for replying. I’m using IIS 8 on Windows 2012 Datacenter.
Where do I get the configuration?
Hi again @Abdul,
I'm afraid I'm a lifelong Linux user 
I don't know anything about IIS or Windows servers.
I've updated the title of this post to hopefully attract some other folks with familiarity to help out.
Good luck!
Alright. No problem! Thanks for the help. 
1 Like
I cannot give you a personal recommendation since I haven’t used IIS but I can say that this:
https://www.nartac.com/Products/IISCrypto
… Sounds like a sensible way for less than expert users to tinker with these settings on Windows.
Keep in mind that shiny new things aren’t necessarily better. Particularly if your site is visited by people you don’t know, rather than just yourself and friends it will be important to be compatible with the software people actually use, even if it’s not the latest breakthrough technology.
2 Likes
I’ve used IISCrypto where I work and can verify that it is a good solution for making sure weak cyphers are disabled. Keep in mind that configuring the cipher settings affects everything that uses Windows’ native crypto, including RDP. Choosing the wrong settings can break RDP and other remote connection tools, so make sure you have some way to access the console before changing settings. If you’re not sure what to set, the “best” preset works very well.
1 Like
Unless special steps have been taken, the default for Windows RDP uses SHA1 - so don’t disable SHA1 for RDP to continue working.
Normally I would be recommending the exact opposite; but in this one case, yes keep SHA1 enabled.
You are probably safe to disable RC4, MD5, 3DES.
But check that your domain authentication (if in use) doesn’t rely on 3DES.
There's a particular and important benefit to moving away from RSA ciphersuites.
When you use RSA ciphersuites, the browser creates the random session key¹ and encrypts it with the server's public RSA key. This is a super-classic use of RSA for public-key cryptography. The session key is then used to actually encrypt all of the communications between the browser and the server (in this case using some block cipher mode based on AES-128).
But in this case, the server continues to have the ability to decrypt old key exchange messages from communications that may have happened years ago. It doesn't matter if the server doesn't keep any logs at all—just having the RSA private key will still allow it to decrypt those old key exchanges and learn what the session key would have been. (You can see this with the Wireshark packet sniffer, where you have the ability to input a server RSA private key and then decrypt TLS sessions inside Wireshark, as long as those sessions used an RSA key exchange.) Therefore, if anyone has recorded an old session and later learns the private key in any way, that person can decrypt that old session, even after an unlimited amount of time has passed.
With forward-secret ciphersuites that use Diffie-Hellman-style key exchange methods, there is an additional ephemeral secret which is never transmitted over the network. This has the result that the server, unless specifically designed to keep certain extra logs, loses the ability to decrypt its old traffic after the end of a session². That means that someone who has recorded an old session can no longer decrypt it even using any amount of secret information from the server.
There are still mathematical assumptions in play about the inability of attackers to break the cryptography through mathematical methods. For example, among other things, if they can solve the DLP or ECDLP, they can still decrypt the session even without the server's help. So far, this appears to be hard to do. 
However, there's concern that quantum computers will make it easier.
However, without forward-secret key exchange methods, there is a very direct way that an attacker can read old traffic without any particularly challenging or innovative math, and that's getting ahold of the server private key—like I mentioned about importing it into Wireshark. With the forward-secret methods, you eliminate this avenue of attack and greatly increase the likelihood that already-concluded sessions will remain secure against a very large range of adversaries. So that's a specific way that more modern cryptography improves users' security.
I'd agree with the intuition about not upgrading just for the sake of upgrading, but our knowledge of cryptography is also getting better over time and there are ways that some of the newer things provide better protection. We've suggested following the advice from
https://wiki.mozilla.org/Security/Server_Side_TLS
because it was prepared by experts who thought a lot about the details. (I also collected a bunch of other expert advice in this area but we ultimately decided that the Mozilla expert advice is just fine and that there wasn't a clear benefit to giving people a huge amount of possibly slightly contradictory material to wade through.)
¹ Very slightly oversimplifying the process.
² Also somewhat oversimplifying the process, because implementations have flexibility about the frequency with which they change their DH secrets. But it can be different per-session.
2 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.