开发者

https: Apache TLS renegotiation: Debian, Apache2, openssl. How to?

On modern browsers, my site gets marked as sorta insecure:

Google Chrome for example says "The server does not support the TLS renegotiation extension" in the "Page Information".

HTTPS runs fine though, the connection is encrypted and the certificate is valid.

# openssl version
OpenSSL 0.9.8g 19 Oct 2007

# cat /etc/debian_version
5.0.6

# apache2ctl -V
Server version: Apache/2.2.9 (Debian)
Server built:   Apr 20 2010 21:4开发者_运维技巧4:40
Server's Module Magic Number: 20051115:15
Server loaded:  APR 1.2.12, APR-Util 1.2.12
Compiled using: APR 1.2.12, APR-Util 1.2.12
Architecture:   64-bit
Server MPM:     ITK
  threaded:     no
    forked:     yes (variable process count)
Server compiled with....
 -D APACHE_MPM_DIR="server/mpm/experimental/itk"
 -D APR_HAS_SENDFILE
 -D APR_HAS_MMAP
 -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
 -D APR_USE_SYSVSEM_SERIALIZE
 -D APR_USE_PTHREAD_SERIALIZE
 -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
 -D APR_HAS_OTHER_CHILD
 -D AP_HAVE_RELIABLE_PIPED_LOGS
 -D DYNAMIC_MODULE_LIMIT=128
 -D HTTPD_ROOT=""
 -D SUEXEC_BIN="/usr/lib/apache2/suexec"
 -D DEFAULT_PIDLOG="/var/run/apache2.pid"
 -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
 -D DEFAULT_LOCKFILE="/var/run/apache2/accept.lock"
 -D DEFAULT_ERRORLOG="logs/error_log"
 -D AP_TYPES_CONFIG_FILE="/etc/apache2/mime.types"
 -D SERVER_CONFIG_FILE="/etc/apache2/apache2.conf"

I'm using the dotdeb repository for my LAMP setup, hence Apache 2.2.9.

  • Is there something wrong with my server configuration?

  • Or is there something wrong with the certificate in use?

  • Where should I begin tracking down the issue?


According to the Debian changelog, you're using the apache2 package version 2.2.9-10+lenny8 (the latest one available for Lenny), built Apr 20 2010. Version 2.2.9-10+lenny6 had introduced a quick fix for the problem (CVE-2009-3555):

Reject any client-initiated SSL/TLS renegotiations. This is a partial fix for the TLS renegotiation prefix injection attack (CVE-2009-3555). Any configuration which requires renegotiation for per-directory/location access control or uses "SSLVerifyClient optional" is still vulnerable.

Therefore, you should disable SSLVerifyClient optional in Directory or Location directives.

The TLS renegotiation extension (RFC 5746), which addresses the problem in SSLVerifyClient optional more generally, was implemented in OpenSSL versions 0.9.8m and 1.0.0a, which you would need if you wanted to use it.

If you're not using SSLVerifyClient optional in location/directory directives, your configuration doesn't seem insecure, it just doesn't support this TLS extension that would have allowed you to keep using client-certificate authentication on a per-directory/location basis.

Apache Httpd 2.2.15 also introduced the SSLInsecureRenegotiation directive if you want to force the insecure behaviour (and use OpenSSL 0.9.8m or above).


I'm not sure why but I stumbled into what appears to be a fix for this issue. I had only 1 vhost for SSL and noticed a redirect from http -> https wasn't working. I tried a number of variations of the rewrite rules to no avail. So I decided to create a second vhost on port 80. The redirect started working and not only that, Chrome started showing the green https symbol in the corner :D

0

上一篇:

下一篇:

精彩评论

暂无评论...
验证码 换一张
取 消

最新问答

问答排行榜