[Issues] [mod_gnutls 0000087]: mod_gnutls doesn't work with mod_proxy_http
Mantis Bug Tracker
issues at outoforder.cc
Mon Jul 20 17:18:09 EDT 2009
The following issue has been set as RELATED TO issue 0000097.
======================================================================
http://issues.outoforder.cc/view.php?id=87
======================================================================
Reported By: csak
Assigned To: nmav
======================================================================
Project: mod_gnutls
Issue ID: 87
Category: Other
Reproducibility: always
Severity: major
Priority: normal
Status: resolved
Apache Version: Apache/2.2.8 (Debian) DAV/2 SVN/1.4.6
mod_gnutls/0.5.1 mod_ssl/2.2.8 OpenSSL/0.9.8g
Resolution: fixed
Fixed in Version:
======================================================================
Date Submitted: 2008-06-13 13:13 EDT
Last Modified: 2009-01-04 11:09 EST
======================================================================
Summary: mod_gnutls doesn't work with mod_proxy_http
Description:
We get this error when we try to use mod_gnutls to proxy a service. The
proxying works on the similarly configured HTTP virtualhost.
The certificate is returned to the client, but then the borwser just
doesn't receive data until timeout.
I'm using a cacert.org class 3 certificate which works flawlessly on
OpenSSL.
The server produces the error message GnuTLS: Handshake Failed. Hit
Maximum Attempts.
The system is running an up-to date version of debian testing.
======================================================================
Relationships ID Summary
----------------------------------------------------------------------
related to 0000097 Support for proxying from SSL to plain ...
======================================================================
----------------------------------------------------------------------
(0000122) nmav (manager) - 2008-10-16 14:24
http://issues.outoforder.cc/view.php?id=87#c122
----------------------------------------------------------------------
Would increasing the HANDSHAKE_MAX_TRIES to 1024 in gnutls_io.c solve your
issue?
----------------------------------------------------------------------
(0000123) nmav (manager) - 2008-10-16 14:26
http://issues.outoforder.cc/view.php?id=87#c123
----------------------------------------------------------------------
Need feedback on the HANDSHAKE_MAX_TRIES proposal.
----------------------------------------------------------------------
(0000133) llucax (reporter) - 2008-11-03 09:26
http://issues.outoforder.cc/view.php?id=87#c133
----------------------------------------------------------------------
Please, see thread
http://lists.outoforder.cc/pipermail/modules/2008-October/000202.html
I think the problem is the proxied server is receiving the encrypted data
instead of the decrypted HTTP request.
----------------------------------------------------------------------
(0000134) nmav (manager) - 2008-11-03 14:15
http://issues.outoforder.cc/view.php?id=87#c134
----------------------------------------------------------------------
Ah, thank you. Would be easy for you to post a simple mod_proxy
configuration for me to check this issue?
----------------------------------------------------------------------
(0000135) llucax (reporter) - 2008-11-03 15:42
http://issues.outoforder.cc/view.php?id=87#c135
----------------------------------------------------------------------
Did you see the example in the linked e-mail in the previous comment? I'll
copy it here just in case:
--------------------------------------------------
Let's say we have:
A B C
HTTPS client ------ HTTPS server ------- HTTP server
A makes a request to B, B forwards it to C but using SSL, so B expects
that C sends the SSL client hello handshake. But C is HTTP (without S),
so
he hangs wainting for B to send him the request.
So everybody waits until the famous timeout expires.
I did a simple example that seems to confirm that:
<VirtualHost *:443>
ServerName vhost.example.com
GnuTLSEnable on
GnuTLSExportCertificates on
GnuTLSPriorities SECURE
GnuTLSCertificateFile /etc/ssl/certs/apache/example.crt
GnuTLSKeyFile /etc/ssl/certs/apache/example.key
DocumentRoot /var/www/example
ProxyRequests Off
<Proxy *>
AuthUserFile /etc/apache2/htpasswd
AuthName "Terminal Web"
AuthType Basic
require valid-user
Order Deny,allow
Allow from all
</Proxy>
ProxyPreserveHost On
ProxyPass / http://localhost:8022/
ProxyPassReverse / http://localhost:8022/
</VirtualHost>
Then I run this python script:
import socket
s = socket.socket()
s.bind(('0.0.0.0', 8022))
s.listen(10)
(sc, addr) = ss.accept()
sslsc = socket.ssl(sc)
print sslsc.read(1000)
And this is printed:
GET / HTTP/1.1\r\n
--------------------------------------------------
Please let me know if you need anything else.
Thank you for your time.
----------------------------------------------------------------------
(0000136) llucax (reporter) - 2008-11-04 07:29
http://issues.outoforder.cc/view.php?id=87#c136
----------------------------------------------------------------------
Of course you can omit the "Auth" part of the apache configuration =)
----------------------------------------------------------------------
(0000138) AlainKnaff (reporter) - 2008-12-30 08:58
http://issues.outoforder.cc/view.php?id=87#c138
----------------------------------------------------------------------
It seems that the reason for this behavior is that the
mgs_hook_pre_connection is being called both for incoming and outgoing
(mod_proxy) connections.
The attached patch (mod_proxy.patch) tries to find out in which case we
are, and returns OK without doing anything if it is an outgoing
connection.
The method of telling both cases apart (namely, checking whether remote
address' hostname is set) may seem somewhat hackish, but it does work,
even if
HostnameLookups is set to On.
If ever there is a problem with this method, we might need to check local
port instead (whether it is 443), but that would break if a non-standard
https port was used.
----------------------------------------------------------------------
(0000139) llucax (reporter) - 2008-12-30 13:05
http://issues.outoforder.cc/view.php?id=87#c139
----------------------------------------------------------------------
The patch worked for me.
Thanks!
----------------------------------------------------------------------
(0000141) nmav (manager) - 2009-01-04 11:10
http://issues.outoforder.cc/view.php?id=87#c141
----------------------------------------------------------------------
The patch by Alain fixes the issue, thus I'm preparing a new release
including it. Thank you!
Issue History
Date Modified Username Field Change
======================================================================
2008-06-13 13:13 csak New Issue
2008-06-13 13:13 csak Apache Version => Apache/2.2.8
(Debian) DAV/2 SVN/1.4.6 mod_gnutls/0.5.1 mod_ssl/2.2.8 OpenSSL/0.9.8g
2008-10-16 14:24 nmav Note Added: 0000122
2008-10-16 14:26 nmav Note Added: 0000123
2008-10-16 14:26 nmav Assigned To => nmav
2008-10-16 14:26 nmav Status new => feedback
2008-10-18 01:29 nmav Issue Monitored: nmav
2008-11-03 09:26 llucax Note Added: 0000133
2008-11-03 14:15 nmav Note Added: 0000134
2008-11-03 15:42 llucax Note Added: 0000135
2008-11-04 07:29 llucax Note Added: 0000136
2008-12-30 08:52 AlainKnaff File Added: mod_proxy.patch
2008-12-30 08:58 AlainKnaff Note Added: 0000138
2008-12-30 13:05 llucax Note Added: 0000139
2009-01-04 11:09 nmav Note Added: 0000141
2009-01-04 11:09 nmav Status feedback => resolved
2009-01-04 11:09 nmav Resolution open => fixed
2009-01-04 11:10 nmav Note Edited: 0000141
2009-07-20 17:18 nmav Relationship added related to 0000097
======================================================================
More information about the Issues
mailing list