|
Home > Archive > Perlbal > September 2006 > SSL handshake blocks Perlbal
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
SSL handshake blocks Perlbal
|
|
| Alessandro Ranellucci 2005-11-08, 5:53 pm |
| Greetings,
an easy way to block an instance of Perlbal running SSL is to open a
telnet session to its port. The accept() method will then wait for
client handshake, thus blocking the whole application.
See this thread for further information:
http://www.cpanforum.com/threads/433
We would need a non-blocking IO::Socket::SSL port. :-(
Brad, any clue?
- alessandro ranellucci.
| |
| Brad Fitzpatrick 2005-11-08, 5:53 pm |
| I feared something like this might happen.
I have no answer except begging the IO::Socket::SSL maintainer to look at
Perlbal and try to fix make IO::Socket::SSL non-blocking in that phase. :/
- Brad
On Mon, 7 Nov 2005, Alessandro Ranellucci wrote:
> Greetings,
>
> an easy way to block an instance of Perlbal running SSL is to open a
> telnet session to its port. The accept() method will then wait for
> client handshake, thus blocking the whole application.
>
> See this thread for further information:
> http://www.cpanforum.com/threads/433
>
> We would need a non-blocking IO::Socket::SSL port. :-(
> Brad, any clue?
>
> - alessandro ranellucci.
>
>
| |
| Elliot F 2006-05-22, 7:11 am |
| Not to bring up a relatively old topic, but has this subject been
pursued at all?
Brad Fitzpatrick wrote:[vbcol=seagreen]
> I feared something like this might happen.
>
> I have no answer except begging the IO::Socket::SSL maintainer to look at
> Perlbal and try to fix make IO::Socket::SSL non-blocking in that phase. :/
>
> - Brad
>
>
> On Mon, 7 Nov 2005, Alessandro Ranellucci wrote:
>
>
| |
| Brad Fitzpatrick 2006-05-22, 1:11 pm |
| 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.
On Mon, 22 May 2006, Elliot Foster wrote:
> Not to bring up a relatively old topic, but has this subject been
> pursued at all?
>
> Brad Fitzpatrick wrote:
>
>
| |
| Mike Whitaker 2006-08-26, 7:11 am |
|
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?
| |
| Elliot F 2006-08-28, 1:12 pm |
| 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:
>
>
> Any progress on this?
| |
| Brad Fitzpatrick 2006-08-28, 1:12 pm |
| 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:
>
>
| |
|
| 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@danga.com>
wrote:
[vbcol=seagreen]
> 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:
>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
| |
| Mark Smith 2006-09-16, 1:13 pm |
| On Mon, Aug 28, 2006, Sam G wrote:
> 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:
We've experimented with similar and used to use Pound too, it worked but
once in a while would get stuck?
> 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?
Usage: HEADER <service> {INSERT|REMOVE} <header>[: <value>]
Use that in your config file...
HEADER web_proxy REMOVE X-App-SSL
This gets run at the last possible instant before the headers are
written out to the backend webserver.
--
Mark Smith
junior@danga.com
|
|
|
|
|