Onion Information

Page Clicks: 1

First Seen: 03/11/2024

Last Indexed: 10/25/2024

Domain Index Total: 195

The TLS world is moving fast and this post is now out of date! You might want to look at the SSL configuration recommended by Mozilla . After recently reading a number of SSL/TLS -related articles, I decided to experiment and look for the ideal OpenSSL configuration for Apache (using mod_ssl since I haven't tried mod_gnutls yet) and nginx . By "ideal" I mean that this configuration needs to be compatible with most user agents likely to interact with my website as well as being fast and secure . Here is what I came up with for Apache: SSLProtocol TLSv1 SSLHonorCipherOrder On SSLCipherSuite RC4-SHA:HIGH:!kEDH and for nginx: ssl_protocols TLSv1; ssl_ciphers RC4-SHA:HIGH:!kEDH; ssl_prefer_server_ciphers on; Cipher and protocol selection In terms of choosing a cipher to use, this configuration does three things: disables all weak ciphers and protocols disables very slow ciphers that use ephemeral Diffie-Hellman exchanges gives priority to the RC4 cipher to minimize CPU usage and defend against the BEAST attack Testing tools The main tool I used while testing various configurations was the SSL labs online tool . The CipherFox extension for Firefox was also quite useful to quickly identify the selected cipher. Of course, you'll want to make sure that your configuration works in common browsers, but you should also test with tools like wget , curl and httping . Many of the online monitoring services are based on these. Other considerations To increase the performance and security of your connections, you should ensure that the following features are enabled: SSL session caching with a session store shared between all of your web servers HSTS headers to let browsers know that they should always visit your site over HTTPS Note: If you have different SSL-enabled name-based vhosts on the same IP address (using SNI ), make sure that their SSL cipher and protocol settings are identical. RSS Atom RC4, while avoiding the attack-flavor-of-the-day, provides relatively weak security compared to other ciphers. Consider the various guides pointing out that "ssh -c arcfour" goes faster but at the expense of some security, and thus that you should not use it on insecure networks. Instead, I'd suggest preferring TLSv1.2 and TLSv1.1, both of which address the BEAST attack and other problems. As far as I know, those already appear earlier in the preference list than TLSv1, though you should check that. @anonymous While it would be nice to be able to switch to TLS 1.2 or 1.1, browser support is not there yet so most clients would simply downgrade to TLS 1.0, hence the need to have a strong TLS 1.0 config. Also, TLS 1.1 requires either a pretty recent version of OpenSSL (not yet in many popular distros) or the use of mod_gnutls. If you aim to be compatible to most browsers you can't use SNI as its incompatible with WinXP IE(all). Thanks, your entries are now in the default configuration of MirBSD httpd and also enabled on www.mirbsd.org and related servers. Another factor to consider is perfect forward secrecy: http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html http://www.imperialviolet.org/2011/11/22/forwardsecret.html http://blog.cryptographyengineering.com/2013/03/attack-of-week-rc4-is-kind-of-broken-in.html Add a comment