2

We are hosting an SaaS website and API with the https protocol, both of which are accessed by numerous users with a lot of different browsers and client-side apps. What would happen if I made PFS mandatory in my IIS Web Server's configuration? Could there be problems with incompatible clients which do not know how to handle PFS?

MCW
  • 2,572
  • 1
  • 15
  • 26
Adrian Grigore
  • 131
  • 3
  • If you support both ECDHE_RSA and DHE_RSA, you'll support most clients. AFAIK Internet explorer on Windows XP doesn't support either. But there is little reason to completely disable RSA, it's enough to ensure that it's only chosen when no better suite is available. – CodesInChaos Nov 25 '13 at 13:09
  • @CodesInChaos don't you think the connection will be vulnerable to MITM? SSL parameres exchange is done in plaintext. – Smit Johnth Nov 26 '13 at 07:27
  • @SmitJohnth I don't get your point. SSL's MitM prevention is as good as the certificate validation. It doesn't matter if SSL parameters are in the clear. – CodesInChaos Nov 26 '13 at 08:32
  • @CodesInChaos Are SSL connection parameters part of certificate? – Smit Johnth Nov 26 '13 at 15:20
  • @SmitJohnth Not part of the certificate itself, but they're authenticated with the certificate as part of the handshake. There are some tricky details, but as long as all your ciphersuites are decent (which includes some plain RSA suites) an attacker can't modify the parameters. – CodesInChaos Nov 26 '13 at 15:21
  • @CodesInChaos at least client's parameters are transmitted unprotected. Can the mitmer tell the server the clent doesn't support DHE? – Smit Johnth Nov 26 '13 at 22:25
  • 1
    @SmitJohnth - since SSL 3.0 this has been protected. Once the cipher has been agreed the negotiation phase is repeated, but encrypted this time, and if it doesn't match the original, the connection is dropped. – paj28 Dec 05 '13 at 14:04
  • @paj28 nothing is 'repeated encrypted'. Ciphersuite is agreed by ServerHello. The prior ClientHello is not repeated or encrypted, and the subsequent messages up to but not including CCS are not encrypted, with the single (important) exception of ClientKX data for plain-RSA. Some messages are signed, but signature is not encryption. BUT all handshake messages, including the Hello's, are AUTHENTICATED by the Finished exchange. See the correct and canonical http://security.stackexchange.com/questions/20803/how-does-ssl-tls-work/20847#20847 . – dave_thompson_085 Jul 13 '14 at 23:00
  • Oops! I meant through CCS (up to not including Finished), but can't edit. – dave_thompson_085 Jul 13 '14 at 23:15

2 Answers2

1

All major browsers support ECDHE: IE since IE7 (on Vista and newer), and Chrome and Firefox for even longer. However, Windows XP users of IE do not get ECDHE support, and even though Windows XP is past end-of-life, people are still using it. If you want to allow XP users, then I suggest just putting the ECDHE modes at the top of your cipher preference string. If you value PFS over Windows XP users, then create a cipher preference string with only ECDHE modes.

Qualsys's SSL Labs has a great article on deploying PFS, and of course their checker will help you figure out which browsers will negotiate with which cipher suite.

David
  • 15,814
  • 3
  • 48
  • 73
0

Most of the modern webbrowsers do support PFS. I would recommend you to check your server configuration with https://www.ssllabs.com/ssltest/

You may check the capabilities of specific browser explicitely as well here https://www.ssllabs.com/ssltest/viewMyClient.html

hth

binaryanomaly
  • 1,291
  • 3
  • 13
  • 21