Bug 44503 - Errors during SSL handshake
Errors during SSL handshake
Status: NEEDINFO
Product: Apache httpd-2
Classification: Unclassified
Component: mod_ssl
2.2.4
Sun OpenBSD
: P2 blocker with 1 vote (vote)
: ---
Assigned To: Apache HTTPD Bugs Mailing List
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2008-02-27 18:09 UTC by Brendon Matthews
Modified: 2008-03-02 12:00 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Brendon Matthews 2008-02-27 18:09:44 UTC
I have installed a standard apache 2.2.4 package on OpenBSD 4.2, and have found a major problem.

I set up 4 virtual hosts on the same IP address:
*.80 -> no ssl
XXX.XXX.XXX.XXX:443 -> SSL enabled
XXX.XXX.XXX.XXX:40002 -> SSL enabled
XXX.XXX.XXX.XXX:40003 -> SSL enabled
All 3 have been configured correctly to use SSL, and each one uses its own dummy SSL certificate.

The server starts fine, and all 3 virtual hosts work as expected. Testing each one individually on a web browser shows that they all work fine.
However, after a period of time under a moderate load the 3rd SSL site starts to have great difficulty figuring out which host it's supposed to be using, and ends up dropping out of SSL to the default virtual host on port 80. But this seems to happen AFTER the browser has already established the initial handshake with SSL.

This results in errors similar to the following in the default host's error log: 
[Tue Feb 26 16:35:00 2008] [error] [client XXX.XXX.XXX.XXX] Invalid method in request \x16\x03\x01
The SSL virtual host shows no errors, even with the LogLevel set to debug.
The web browser comes up with an error message: "Unrecognized SSL message, plaintext connection?"

If i disable all SSL virtual hosts and enable each one individually i get no errors, even under a heavy load, so the configuration seems to be fine. There just seems to be a major problem with the mod_ssl module making it unable to handle more than one SSL host for very long.
Comment 1 Nick Kew 2008-02-28 05:29:30 UTC
Could this be another manifestation of Bug 43218?
Comment 2 Brendon Matthews 2008-02-28 12:18:03 UTC
I have just implemented the workaround suggested in bug 43218, but the problem still persists. But from the looks of it, this could be related.

It looks like it's only happening when 2 or more requests come in at around the same time, suggesting some kind of synchronization issue between requests?

I wondered if perhaps it was something to do with the SSL Session Cache:
SSLSessionCache         shm:logs/ssl_scache(512000)

Once apache is started i can see the following in the logs:
[Fri Feb 29 09:04:29 2008] [info] Shared memory session cache initialised

However, it looks like the shared memory file is never created.
There is no file named ssl_scache in my logs directory, and there are no shared memory segments showing up either:

# ipcs 
Message Queues:
T       ID     KEY        MODE       OWNER    GROUP

Shared Memory:
T       ID     KEY        MODE       OWNER    GROUP

Semaphores:
T       ID     KEY        MODE       OWNER    GROUP

Whatever value i use for SSLSessionCache appears to make no difference to the stability of the server.

I get the same sort of problem with the SSLMutex directive:
SSLMutex  file:logs/ssl_mutex
- No file is ever created

I hope all this helps.
Comment 3 Joe Orton 2008-02-29 12:09:29 UTC
Please give a minimal configuration which reproduces this error.
Comment 4 Brendon Matthews 2008-03-02 12:00:57 UTC
Configs are as follows:

<VirtualHost *:80>
    DocumentRoot "/var/apache2/htdocs"
    ServerName default.myhost.com
    ServerAdmin me@something.com
</VirtualHost>

<VirtualHost 192.168.1.16:443>
DocumentRoot /var/web/test
ServerName test.myhost.com
ServerAdmin me@something.com
SSLEngine on
SSLCertificateFile    /etc/apache2/server.crt
SSLCertificateKeyFile /etc/apache2/server.key
CustomLog logs/testsite.ssl_request_log \
          "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
SetEnvIf User-Agent ".*MSIE.*" nokeepalive \
          ssl-unclean-shutdown downgrade-1.0 force-response-1.0
</VirtualHost>

<VirtualHost 192.168.1.16:40002>
DocumentRoot /var/web/test2
ServerName test2.myhost.com
ServerAdmin me@something.com
SSLEngine on
SSLCertificateFile    /etc/apache2/server2.crt
SSLCertificateKeyFile /etc/apache2/server2.key
CustomLog logs/testsite2.ssl_request_log \
          "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
SetEnvIf User-Agent ".*MSIE.*" nokeepalive \
          ssl-unclean-shutdown downgrade-1.0 force-response-1.0
</VirtualHost>

<VirtualHost 192.168.1.16:40003>
DocumentRoot /var/web/test3
ServerName test3.myhost.com
ServerAdmin me@something.com
SSLEngine on
SSLCertificateFile    /etc/apache2/server3.crt
SSLCertificateKeyFile /etc/apache2/server3.key
CustomLog logs/testsite3.ssl_request_log \
          "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
SetEnvIf User-Agent ".*MSIE.*" nokeepalive \
          ssl-unclean-shutdown downgrade-1.0 force-response-1.0
</VirtualHost>

NOTE: I get the same results when i configure 3 different IP addresses using port 443, but this is an easier configuration to test.