SSL handshake blocks Perlbal

[Sam G]

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/