Warning: please only use the recommendations for Apache configuration from the answers below. For which cipher(s) to use - security norms change over time and some of the security advice below is already out of date.
In the wake of recent events, I have been reconsidering my Apache setup. Currently, my apache site config looks something like this:
<IfModule mod_ssl.c>
<VirtualHost *:80>
ServerName example.com
ServerAlias www.example.com
Redirect permanent / https://example.com
</VirtualHost>
<VirtualHost *:443>
ServerAdmin webmaster#localhost
ServerName example.com
DocumentRoot /var/www-wordpress
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
<Directory /var/www-wordpress>
Options Indexes FollowSymLinks MultiViews
AllowOverride FileInfo
Order allow,deny
allow from all
</Directory>
ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
<Directory "/usr/lib/cgi-bin">
AllowOverride None
Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
Order allow,deny
Allow from all
</Directory>
ErrorLog ${APACHE_LOG_DIR}/error.log
LogLevel warn
CustomLog ${APACHE_LOG_DIR}/ssl_access.log combined
SSLCertificateFile /etc/ssl/certs/example.com.crt
SSLCertificateKeyFile /etc/ssl/private/example.com.key
SSLCertificateChainFile /etc/ssl/certs/sub.class1.server.ca.pem
<FilesMatch "\.(cgi|shtml|phtml|php)$">
SSLOptions +StdEnvVars
</FilesMatch>
<Directory /usr/lib/cgi-bin>
SSLOptions +StdEnvVars
</Directory>
BrowserMatch "MSIE [2-6]" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown
</VirtualHost>
What do I have to do to support perfect forward secrecy? How can I enable SSL perfect forward secrecy by default? How could I enforce it?
How about:
SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder On
SSLCipherSuite EECDH+AES:EDH+AES:-SHA1:EECDH+RC4:EDH+RC4:RC4-SHA:EECDH+AES256:EDH+AES256:AES256-SHA:!aNULL:!eNULL:!EXP:!LOW:!MD5
Note the addition of the -SSLv3 flag to disable SSLv3. This is added to protect against the POODLE attack.
This will prefer perfect forward secrecy, but not at the expense of being vulnerable to the BEAST attack. Since Apache lacks a way to configure cipher preference based on protocol version, I fake it by referring to ciphers only available in the newer protocols. Specifically, AES was only available with SHA1 hashing until TLSv1.2. Thus the list starts with the TLSv1.2 ephemeral Diffie-Hellman ciphers, then RC4 (first with ephemeral DH, then without), and finally a BEAST-vulnerable AES option. Excluding no auth / weak encryption / weak hashing at the end is just for good hygiene and could be omitted since no such ciphers were introduced. If performance is a concern, use EECDH only and omit EDH.
In combination with Apache 2.2 (thus no EECDH as #Bruno says), per https://www.ssllabs.com/ssltest/analyze.html, this achieves PFS for iOS Safari only. IE and Firefox are TLSv1.0 so they get RC4 to avoid BEAST. (Alas, there is no such thing as EDH RC4, so without EECDH, you give up PFS). This is, I believe, the best one could hope for with those browsers on Apache 2.2. Chrome is the only one poorly served, since it supports TLSv1.1 and could use EDH AES without being vulnerable to BEAST. Instead, it gets RC4-RSA like Firefox and IE. Upgrading Apache to enable EECDH RC4 should get PFS for Firefox, IE, and Chrome.
Update 2013-11-09:
I've found a few alternate recommendations around the web. They put less emphasis on BEAST protection (perhaps wise; BEAST is mostly mitigated client-side now) and more emphasis on perfect forward secrecy. To varying degrees they also have stronger preferences for GCM and greater reluctance to accept RC4.
Of particular note are, I think, the following recommendations:
Mozilla OpSec
Ivan Ristic (of Qualys)
Geoffroy Gramaize
Personally, I'm going to go with Mozilla OpSec's. Their reasoning is well explained on their page. Of note, they prefer AES128 over AES256. In their words: "[AES128] provides good security, is really fast, and seems to be more resistant to timing attacks."
Noteworthy in Ivan Ristic's and Geoffroy Gramaize's recommendation is that SSLv3 is disabled. I think this mostly just breaks IE6, though some security related differences between SSLv3 and TLS v1.0 are mentioned on Wikipedia.
Also before I didn't talk about CRIME and BREACH. To protect against CRIME, disable SSL compression. This is included in the examples linked. To protected against BREACH, you need to disable compression at the HTTP level. For Apache 2.4, just do this once globally:
<Location />
SetEnvIfExpr "%{HTTPS} == 'on'" no-gzip
</Location>
For older versions of Apache, place this in each VirtualHost where SSLEngine is on:
<Location />
SetEnv no-gzip
</Location>
Update 2014-10-14:
The Mozilla OpSec guide is now split into recommendations for old/intermediate/modern compatibility. With the settings from intermediate or modern, you end up with SSLv3 disabled. That will protect against the POODLE attack.
From my own understanding, you need to activate SSLHonorCipherOrder and to prepend SSLCipherSuite with ECDHE and DHE ciphers from openssl ciphers -v
From my /etc/apache2/mods-available/ssl.conf:
SSLHonorCipherOrder on
SSLCipherSuite ECDHE-RSA-RC4-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA:DHE-RSA-CAMELLIA128-SHA:AES128-SHA:RC4-SHA:HIGH:!aNULL:!MD5:!ADH
To test your website, you can use: https://www.ssllabs.com/ssltest
Note: Eliptic Curve DHE only seems to work with Apache 2.3.3 or higher (see source and Bruno's comment).
The cipher suites that provide Perfect Forward Secrecy are those that use an ephemeral form of the Diffie-Hellman key exchange. Their disadvantage is their overhead, which can be improved by using the elliptic curve variants (see Vincent Bernat's blog.)
The cipher suites in Apache Httpd (provided you're using mod_ssl compiled with OpenSSL) are configured using SSLCipherSuite, which takes a list as you would see when using the openssl ciphers command. If you look at the OpenSSL man page, you'll find kEDH is what you're looking for. (You can also list cipher suites individually.)
Enter this cipher code in your httpd.conf in the main/core conf directive:
SSLCipherSuite AES128+EECDH:AES128+EDH
SSLProtocol All -SSLv2 -SSLv3
SSLHonorCipherOrder On
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"
Header always set X-Frame-Options DENY
Header always set X-Content-Type-Options nosniff
# Requires Apache >= 2.4
SSLCompression off
SSLUseStapling on
SSLStaplingCache "shmcb:logs/stapling-cache(150000)"
You can even check the status of how secure it is by testing it at: https://www.ssllabs.com/ssltest/analyze.html?
Try this code in your ssl.conf:
SSLProtocol +TLSv1.2 +TLSv1.1 +TLSv1
SSLCompression off
SSLHonorCipherOrder on
SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-RC4-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:RC4-SHA:AES256-GCM-SHA384:AES256-SHA256:CAMELLIA256-SHA:ECDHE-RSA-AES128-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:CAMELLIA128-SHA
By the way,
Expert tip: The (1/n-1) split record trick is implemented in Firefox since a while. Thus, you can safely disable RC4 on Firefox in the advanced configuration menu. To do so, enter ‘about:config’ in your address bar, then search for ‘rc4′ and toggle all the found values to ‘false’. If you experience connections issues, toggle back those parameters to true.
https://cc.dcsec.uni-hannover.de/
This websites gives you information on the SSL cipher suites your browser supports for securing HTTPS connections.
Have a look at https://cipherli.st
There you find copy & paste config snippets for several services, that should ensure strong ssl security settings.
This article will help you configure forward security and get you up to date on current standards - https://community.qualys.com/blogs/securitylabs/2013/08/05/configuring-apache-nginx-and-openssl-for-forward-secrecy
As of 09/16/2015, this will get you an A on SSLLabs test results.
SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder On
SSLCipherSuite EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:EDH+aRSA:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4
I got a grade A (Sept. 2016) on SSLLabs still supporting Windows XP / Internet Explorer 8 using this ssl.conf configuration on Apache:
SSLProtocol All -SSLv2 -SSLv3
SSLHonorCipherOrder on
SSLCipherSuite EECDH+AESGCM:AES256+EECDH:DES-CBC3-SHA
In brief: only TLS is allowed: all versions are supported for compatibility and DES-CBC3-SHA cipher is allowed for compatibility too. The first, preferred two ciphers are using Elliptic curve Diffie-Hellman, the last was added as a fallback because this a good option among the ciphers available XP/IE. If you've installed the last OpenSSL version available this mix is enough to get an A at the time I'm writing.
Hope this is helpful.
Related
I updated apache to last version 2.4.37 and openssl to 1.1.1 and now, when client authenticates, I get this error only with Firefox 63, but not in Chrome:
[ssl:error] AH: verify client post handshake, referer: https://******/login
[ssl:error] AH10158: cannot perform post-handshake authentication, referer: https://******/login
[ssl:error]SSL Library Error: error:14268117:SSL routines:SSL_verify_client_post_handshake:extension not received
I used wireshark to try to find the problem, and I apreciate Firefox uses TLS 1.3, while Chrome uses TLS 1.2. In fact, if I set TLS max version in FF to TLS 1.2, it works fine.
I would like to get TLS 1.3 compatibility or, if it is not yet possible, to force, in my Apache configuration, the client always uses TLS 1.2, but I don't get it :(
This is my apache vhost config file:
[...]
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/server.crt
SSLCertificateKeyFile /etc/apache2/ssl/server.key
SSLCertificateChainFile /etc/apache2/ssl/intermediate.crt
SSLCACertificateFile /etc/apache2/ssl/ca.pem
SSLVerifyDepth 3
SSLProtocol TLSv1.2
SSLHonorCipherOrder on
<Directory /var/www/html/>
Options -Indexes +FollowSymLinks -MultiViews
AllowOverride All
Order deny,allow
Allow from 10.55.12.0/24
Deny from all
</Directory>
<Files "login-ssl.php">
SSLVerifyClient optional
SSLOptions +StdEnvVars +StrictRequire
</Files>
[...]
Can someone help me, please?
Thanks.
Edited
I found the solution. SSLProtocol directive should be in /etc/apache2/mods-enabled/ssl.conf.
The problem is that Firefox doesn't support TLS 1.3 post-handshake authentication. I've reported this issue to Firefox at https://bugzilla.mozilla.org/show_bug.cgi?id=1511989
I'm not suggesting a workaround or fix here; I'm merely telling others who come across this page (as it is high up for this error message in the search results) what the situation is and where to find the latest information as Firefox works to resolve this issue.
In case this helps other, for my reverse proxy test configuration with Apache HTTP 2.4.41 on Windows, I wanted to protect only the balancer-manager URI with client certificate authentication, that I had generated using OpenSSL with CA certs, server certs signed by CA and client cert signed by CA, imported the P12 in my browser.
For my other back end URLs (Spring Boot with AJP enabled and running same application on 2 different set of ports to test balancing via Apache HTTP) that were being proxied, configuration was to do not perform any client certificate authentication.
Accessing https://myhostname.com was working and hitting my back end
via balancer, returning the expected response.
Accessing https://myhostname.com/balancer-manager was expected to
prompt me for selecting client certificate that I imported earlier,
but gave this error on Chrome 80.0 ( and did not work for other
browsers as well).
Forbidden You don't have permission to access this resource.Reason:
Cannot perform Post-Handshake Authentication.
In Apache error log, it showed:
SSL Library Error: error:14268117:SSL
routines:SSL_verify_client_post_handshake:extension not received
In Apache access log, it showed:
GET /balancer-manager HTTP/1.1" 403 199
Non working configuration for Virtual host config in httpd.conf looked like:
<VirtualHost *:443>
ServerName myhostname.com
ServerAlias myhostname.com
SSLEngine on
SSLCipherSuite ALL:!EXP:!eNULL:!aNULL:!MD5:-LOW:-RC4:-SSLv2:+HIGH:+MEDIUM
#no certificate authentication required except balancer manager
SSLVerifyClient none
SSLVerifyDepth 5
SSLProtocol all -SSLv3
SSLCertificateFile "path/to/server/certificate"
SSLCertificateKeyFile "path/to/server/key"
SSLCACertificateFile "path/to/CA/certificate"
<Location "/balancer-manager">
SSLVerifyClient require
SetHandler balancer-manager
Require host myhostname.com
</Location>
<Proxy balancer://cluster>
BalancerMember ajp://localhost:9090/ loadfactor=25 timeout=1
BalancerMember ajp://localhost:9091/ loadfactor=75 timeout=1
ProxySet lbmethod=byrequests
</Proxy>
ProxyPreserveHost off
ProxyRequests Off
ProxyPass / balancer://cluster/ stickysession=JSESSIONID
ProxyPassReverse / balancer://cluster/ stickysession=JSESSIONID
</VirtualHost>
To fix the issue, change SSLProtocol directive to use:
SSLProtocol -all +TLSv1.2
See these links also
Enable TLS in Apache
TLS-1-2
I used TLS 1.2 for tests (TLS 1.1 also worked but recommended to use TLS 1.2 or higher version).
Note:The Apache version 2.4.38 or higher versions support TLS v1.3. You
must upgrade Apache packages before enabled TLS 1.3 in SSL settings.
*
Really hope for some help in my problem with SSLCipherSuite... So i have this kind of virtualhost config:
<VirtualHost *:443>
DocumentRoot /home/webz/site.com
ServerName site.com
ServerAlias www.site.com
SSLProtocol -all +TLSv1.1 +TLSv1.2
SSLHonorCipherOrder on
SSLCipherSuite "kEDH:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+AESGCM:EECDH:EDH+AESGCM:EDH+aRSA:HIGH:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!DHE-RSA-SEED-SHA:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA:!DH+3DES:!DHE-RSA-AES256-GCM-SHA384:!DHE-RSA-AES256-SHA256:!DHE-RSA-AES256-SHA:!DHE-RSA-CAMELLIA256-SHA:!DHE-RSA-DES-CBC3-SHA:!DHE-RSA-AES128-GCM-SHA256:!DHE-RSA-AES128-SHA256:!DHE-RSA-AES128-SHA:!DHE-RSA-CAMELLIA128-SHA:!RC4"
SSLCompression off
SSLEngine on
SSLCertificateFile /etc/httpd/ssl/site.com.crt
SSLCertificateKeyFile /etc/httpd/ssl/site.com.key
SSLCertificateChainFile /etc/httpd/ssl/DigiCertCA.crt
</VirtualHost>
Everything works fine also security is ok by test. (https://cryptoreport.websecurity.symantec.com/checker/views/certCheck.jsp)
PROBLEM: I am trying to install payment module (REDSYS) for Opencart 2. Redsys support team are not activating payment module because they ask me to add one off SSLCipherSuite below:
SSL_RSA_WITH_RC4_128_MD5,
SSL_RSA_WITH_RC4_128_SHA,
SSL_RSA_WITH_AES_128_CBC_SHA,
SSL_RSA_WITH_AES_256_CBC_SHA,
SSL_RSA_WITH_3DES_EDE_CBC_SHA,
SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA
At the moment all SSLCipherSuite starts with TLS... :( So how to add one of those SSLCipherSuites with SSL_RSA... ??? Hope there is somebody who knows good SSL and will help...
According to your configuration you have such cipher suites already. For example you've included AES256-SHA which is the same as TLS_RSA_WITH_AES_256_CBC_SHA. And the SSL_ prefix instead of the TLS_ prefix is just a convention from the old times where TLS was called SSL (i.e. TLS 1.0 is in effect SSL 3.1).
It is more likely that your restriction to TLS 1.1 and TLS 1.2 causes the problem, because given that they require you to use such old ciphers and cannot even handle ECDHE ciphers might indicate that they have a very old client which is not able to speak TLS 1.1 or TLS 1.2.
Of course it might also be that you've included different ciphers in other (i.e. not shown) parts of your server configuration which take precedence. To get information what kind of ciphers your server really supports check your site with SSLLabs.
EDIT: The analysis by SSLLabs shows quite clearly that TLS_RSA_WITH_AES_256_CBC_SHA (which is the same as SSL_RSA_WITH_AES_256_CBC_SHA or AES256-SHA) is enabled on the server as requested. If my assumption is correct the real problem is that they use an old client which does not speak TLS 1.1 or TLS 1.2 yet. In this case you could change your configuration for the supported protocol versions to allow TLS 1.0 too:
SSLProtocol all -SSLv3
With this configuration TLS 1.0 and better (i.e. TLS 1.1, TLS 1.2) are supported.
I've read
How to configure playframework server to support ssl
and I also tried to follow http://www.playframework.org/documentation/1.1.1/releasenotes-1.1#https but it doesn't work for me
many thanks~
I read the doc for Play1 because I can't find any more updated information for Play2 about https.
in application.conf, I added these lines:
https.port=9443
certificate.key.file=conf/host.key
certificate.file=conf/host.cert
I type run in the play console, and try to access the server at https://localhost:9443 the browser timed out without anything logged in the console output
It won't work with the approach you are taking. You are mistaking release notes of 1.x branch with 2.x branch.
in 1.x branch, it is possible. Release notes are sufficient, and they worked for me.
For 2.1+ branch, please refer to #Christina's comment. Support has been added in 2.1 and the discussion thread provides details.
Quoting James Roper's response
In dev mode, it's very easy, just:
JAVA_OPTS=-Dhttps.port=9443 play run
Play will generate a private key and self signed certificate, which
obviously your browser will balk at with a big red warning. It will
reuse that generated self signed certificate for each subsequent run
of Play, so you should only get the browser error once. Obviously
this self signed certificate is probably not what you want in
production. Also important to note is that the self signed
certificate generation will only work on JVMs that use the sun
security libraries (eg Oracle and OpenJDK, but most notably not IBM
J9). On JVMs that don't use these, you will get a
NoClassDefFoundError when it tries to generate the certificate.
In prod (and this config also applies to dev) you configure it much
the same way that you configure SSL ordinarily in Java, via system
properties. Here's a summary:
https.port - The port that should be used
https.keyStore - The path to
the keystore containing the private key and certificate, if not
provided generates a keystore for you
https.keyStoreType - The key
store type, defaults to "JKS"
https.keyStorePassword - The password,
defaults to ""
https.keyStoreAlgorithm - The key store algorithm,
defaults to the platforms default algorithm
https.trustStore - This
feature hasn't been fully implemented, currently it will always use
the JDKs trust store for verifying client side certificates (which you
can of course configure yourself) whether you supply a value for this
or not, unless you specify "noCA", in which case, it will use a trust
store that trusts all certificates with no validation or verification,
which is useful for if using webid client side certificate verification.
For 2.0 branch, you have to put another server infront of play i.e either apache/nginx/other which listens on https and forwards the request to play in http.
Instructions to setup a frontend server are available at http://www.playframework.org/documentation/2.0.1/HTTPServer
So run your play server on a port. Have apache forward request from domain.com to 127.0.0.1:9443.
Sample apache config
<VirtualHost *:443>
ServerAdmin webmaster#localhost
ServerName example.com
ServerAlias *.example.com
ErrorLog ${APACHE_LOG_DIR}/error.log
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel warn
CustomLog ${APACHE_LOG_DIR}/ssl_access.log combined
ProxyPreserveHost On
# ProxyPass /excluded !
ProxyPass / http://127.0.0.1:9000/
ProxyPassReverse / http://127.0.0.1:9000/
# SSL Engine Switch:
# Enable/Disable SSL for this virtual host.
SSLEngine on
# A self-signed (snakeoil) certificate can be created by installing
# the ssl-cert package. See
# /usr/share/doc/apache2.2-common/README.Debian.gz for more info.
# If both key and certificate are stored in the same file, only the
# SSLCertificateFile directive is needed.
SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem
SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
# Certificate Authority (CA):
# Set the CA certificate verification path where to find CA
# certificates for client authentication or alternatively one
<FilesMatch "\.(cgi|shtml|phtml|php)$">
SSLOptions +StdEnvVars
</FilesMatch>
<Directory /usr/lib/cgi-bin>
SSLOptions +StdEnvVars
</Directory>
BrowserMatch "MSIE [2-6]" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
# MSIE 7 and newer should be able to use keepalive
BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown
</VirtualHost>
Hope it helps.
The documentation for setting up the current version of Play (2.2.x) is here:
http://www.playframework.com/documentation/2.2.x/ConfiguringHttps
Right now you seem to need a reverse proxy managing the SSL for you. I found a ticket and a thread discussing this.
This is useful for locally testing https:
activator "run -Dhttps.port=9005"
Then point your browser to https://localhost:9005.
One thing we did was to use AWS ELB to handle our SSL, then setup the SSL forwarding (HTTP -> HTTPS) using a plays filters. The main benefit, takes the SSL load off your server and you don't have to run Apache or Nginx in front of play (as some solution point out).
You can see my answer here:
https://stackoverflow.com/a/23646948/690164
I also write a bit more about it in my blog:
http://www.mentful.com/2014/05/25/play-framework-filter-for-aws-elastic-load-balancer-forward-http-to-https/
I'm using securesocial 3.0.3M. Set
securesocial.ssl = true
in securesocial.conf and you should be good to go.
Then restart your sbt or activator with
JAVA_OPTS=-Dhttps.port=9443 activator run
Go to localhost:9443
enjoy
I'm trying to get a Fedora 14 server running Apache 2.2.17 to pass a PCI-DSS compliance scan by McAfee ScanAlert. My first attempt using the default SSLCipherSuite and SSLProtocol directives set in ssl.conf...
SSLProtocol ALL -SSLv2
SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP
failed citing that weak ciphers were enabled. Scans with ssllabs and serversniff tools revealed that 40 and 56 bit keys were indeed available.
I then changed to...
SSLProtocol -ALL +SSLv3 +TLSv1
and tried all of the following strings reported on various sites to pass PCI scans from assorted vendors...
SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH
SSLCipherSuite ALL:!ADH:!NULL:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:-LOW:+SSLv3:+TLSv1:-SSLv2:+EXP:+eNULL
SSLCipherSuite ALL:!ADH:!NULL:!EXP:!SSLv2:!LOW:RC4+RSA:+HIGH:+MEDIUM
SSLCipherSuite ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM
SSLCipherSuite ALL:!ADH:!NULL:!EXP:!SSLv2:!LOW:!MEDIUM:RC4+RSA:+HIGH
I am restarting apache after updates and apachectl configtest says that my syntax is ok. Subsequent ScanAlert scans have all failed and other scanning tools continue to show 40 and 56 bit ciphers available. I have tried adding SSLProtocol and SSLCipherSuite directly to the VirtualHost in httpd.conf and that has not helped.
It actually feels like something somewhere is overriding these settings but I cannot find anything anywhere that sets these values other than ssl.conf.
If someone could provide a known good SSLCipherSuite that has passed a recent PCI scan it would help a lot in tracking down my problem.
Thanks.
As new vulnerabilities are discovered and browsers are upgraded, the answers here can (will) become outdated. I'd suggest you rely on Mozilla SSL Configuration Generator to check which configuration you should use.
UPDATE 2018: It's reasonable to enforce Perfect Forward Secrecy now, unless you need to support older browsers specifically. As of November 2018, only the "modern" profile will enable Perfect Forward Secrecy. Read more about it at:
SSL Labs: Deploying Forward Secrecy
Configuring Apache, Nginx, and OpenSSL for Forward Secrecy
After hours of searching and hair pulling I found my problem.
The default SSLProtocol and SSLCipherSuite directives in my ssl.conf are stored in a default container labeled as <VirtualHost _default_:443>.
My actual site has it's own container labeled with it's IP address eg: <VirtualHost 64.34.119.12:443>. Changing the values in the _default_ container had no affect but adding the stronger SSLProtocol and SSLCipherSuite directives directly to the site specific VirtualHost container finally allowed them to take effect.
Still not sure why adjusting the _default_ container or having them in the VirtualHost container in httpd.conf didn't work.
As a definitive answer to the question, I used...
SSLCipherSuite ALL:!ADH:!NULL:!EXP:!SSLv2:!LOW:!MEDIUM:RC4+RSA:+HIGH
to pass my ScanAlert scan. I would bet that most of the other strings above would work as well.
Did you tell Apache to enforce cipher order?
SSLHonorCipherOrder on
FYI - I found that this setting:
SSLCipherSuite HIGH:!SSLv2:!ADH
Produced the exact same list of protocols as this setting:
SSLCipherSuite ALL:!ADH:!NULL:!EXP:!SSLv2:!LOW:!MEDIUM:RC4+RSA:+HIGH
According to:
openssl ciphers -v 'ALL:!ADH:!NULL:!EXP:!SSLv2:!LOW:!MEDIUM:RC4+RSA:+HIGH'
openssl ciphers -v 'HIGH:!SSLv2:!ADH'
The following configuration is recommended by Qualys, it gave us a A on their scanner
SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder on
SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS"
Yes, also make sure Apache is able to read the new configuration. I place this directly inside the virtual host container.
From their website: https://community.qualys.com/blogs/securitylabs/2013/08/05/configuring-apache-nginx-and-openssl-for-forward-secrecy
Look here Mozilla Wiki.
The goal of this document is to help operational teams with the configuration of TLS on servers.
Sorry for cross posting, but I wasnt sure whether to post here, or on serverfault.
Safari tells me that it couldnt open the page, because it couldnt establish a secure connection to the server. However, other browsers (opera, firefox) can open the page. Also, theres nothing in the apache error log.
The certificate is selfsigned, and uses standart values. (seen here: http://www.knaupes.net/tutorial-ssl-zertifikat-selbst-erstellen-und-signieren/ )
ssl config:
SSLEngine on
#SSLInsecureRenegotiation on
SSLCertificateFile /home/gemeinde/certs/selfsigned/gemeinde.crt
SSLCertificateKeyFile /home/gemeinde/certs/selfsigned/gemeinde.key
#SSLCACertificateFile /home/gemeinde/certs/Platinum_G2.pem
#SSLOptions +StdEnvVars
<Location "/">
SSLOptions +StdEnvVars +OptRenegotiate
SSLVerifyClient optional
SSLVerifyDepth 10
</Location>
Try SSLInsecureRenegotiation on
I got the same issue , it got resolved when I unchecked the Web Proxy and Secure Web Proxy from System Preferences