SSL handshake blocks Perlbal
Sam G
ceptorial at comcast.net
Tue Aug 29 05:58:26 UTC 2006
Our solution for SSL for now has been to run pound on port 443, and use it
as a simple decrypter and request forwarder to perlbal on port 80. So
Perlbal just receives a normal HTTP request from pound, but with an
X-SSL-Request header to notify our application. Our pound config:
--------
ListenHTTPS
Address 0.0.0.0
Port 443
Cert "/usr/local/etc/pound.pem"
HeadRemove "X-SSL-Request"
AddHeader "X-SSL-Request: 1"
Service
BackEnd
Address 127.0.0.1
Port 80
End
End
End
--------
The only problem is, someone could forge an SSL request by sending that
header through Perlbal. Does Perlbal offer any method to eliminate
specific headers?
-Sam
On Mon, 28 Aug 2006 10:02:42 -0700, Brad Fitzpatrick <brad at danga.com>
wrote:
> Basically SSL can't be hidden away in a library like IO::Socket::SSL
> does,
> at least not in a non-blocking event-based app.
>
> You actually have to deal with all the SSL protocol requirements like
> session renegotiations.
>
>
>
> On Mon, 28 Aug 2006, Elliot F wrote:
>
>> The code looks to be there in djabberd, and I asked if Brad was going to
>> port it, but (if you look at an email I sent on Aug 4th) it looks like
>> Brad isn't going to be able to do it. I may have time in a few months,
>> so if it's not done by then, I may do it.
>>
>> The fix was using Net::SSLeay instead of IO::Socket::SSL.
>>
>> Elliot
>>
>> Mike Whitaker wrote:
>> >
>> > On 22 May 2006, at 16:53, Brad Fitzpatrick wrote:
>> >
>> >> Yes, indirectly: another project of mine, DJabberd, uses the
>> >> Danga::Socket event loop and we've figured out in there how to do SSL
>> >> non-blocking. Need to identify the common code and put it in a
>> >> library or
>> >> something so Perlbal can then use it.
>> >
>> > Any progress on this?
>>
>>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
More information about the perlbal
mailing list