The TLS Deployment Best Practices from SSL Labs is a good read. Thought it might be good to summarize some of it.
Private Key Strength - In order of strength it's 1024bit RSA (low, should be replaced) , then 2048bit RSA ( should be safe for a while ) , and then 256bit ECDSA (best right now if you have support).
Private Key Protection - Guard it with your life, password protect, minimal access, and revoke if compromised.
Private Key Source - Get your keys from a reputable large CA that has strong security posture and services available like simple revocation.
Hash Function - SHA1 is week and should be replaced immediately, SHA2 is the current standard as long as your users can support it.
Protocols - SSL (v2 and v3) are considered broken and should not be used. TLS v1.0 is considered but v1.1 and v1.2 have their advantages that will soon lead to the decom of v1.0
Cipher Suites - You should only be using suites with 128bit encryption or stronger. Also not Anon key exchange suites provide no authentication, NULL suites provide no encryption, Export key exchanges are broken and should not be used, and RC4 is broken and should not be used.
Cipher Suite Selection - Clients submit a list of supported suites and the server chooses one. Having the suites ordered by strength on the server is important so the highest security available is utilized.
Forward Secrecy - This is a feature that makes TLS not use the server's private key but instead a different key each time. The benefit is that if the server's key is compromised, historical traffic cannot be decrypted because the key was not the same.
Renegotiation - It's ok for a Server to initiate a re-negotiation of TLS settings, but there is no reason a Client should. Thus configure the server to ignore Client re-negotiation requests.
TLS & HTTP Compression - They're insecure and most clients don't support TLS Compression, so disable it.
Mixed Content and HSTS - Avoid mixed content of HTTP and HTTPS. Go all or nothing to HTTPS. Otherwise it leads to user confusion, mis-trust, and also some known vulnerabilities related to mixes. Use HSTS (Strict Transport) which tells the browser your site is only ever HTTPS.
Cookies - Cookies must be secured properly by the developer or else it can render your HTTPS ineffective in protecting session and other sensitive information.
EV Certs - You can go one step beyond and get an Extended Verification certificate which goes through extra tests and is harder to forge.
Public Key Pinning - Another above and beyond step that specifies which CAs can issue certificates for your websites.
ECDSA Certs - Elliptical curve certificates provider more strength from smaller key sets which increases performance.
Validate your settings - Run re-occuring tests like ssl labs to ensure your settings are secure.
Keep in mind this information is accurate as of the Dec 2014 publishing of the best practice guide and new information may have surfaced since then that changes some of these stances.
Copyright © 2015, this post cannot be reproduced or retransmitted in any form without reference to the original post.
No comments:
Post a Comment