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.

[ Post a follow-up to this message ]

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.
>
>

[ Post a follow-up to this message ]

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:
>
> 

[ Post a follow-up to this message ]

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: 
>
>

[ Post a follow-up to this message ]

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?

[ Post a follow-up to this message ]

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?

[ Post a follow-up to this message ]

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: 
>
>

[ Post a follow-up to this message ]

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/

[ Post a follow-up to this message ]

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

[ Post a follow-up to this message ]