On Wed, Jan 10, 2001 at 10:55:46AM +0200, Itay Zandbank wrote:
> > You may need to implement this by creating your own in-memory bio so that
> > you can peek at the incoming data to determine whether it is an HTTP
> > request. Then if it's not HTTP, call SSL_accept on your bio.
>
> I was hoping I could keep ignoring this entire bio issue, because I didn't
> find it all that exciting, and because I'm not sure m2crypto (a lowlevel
> Python wrapping of the OpenSSL library) supports it.
>
> Anyway, I would really like OpenSSL to decide whether it's an SSL
> connection or not (it's more general, because the underlying protocol might
> change in the future). I guess I could still use my own bio that remembers
> everything that goes through it, and when SSL_accept fails, access the data
> there.
>
> Doesn't OpenSSL have built-in support for it (something to call after
> SSL_accept to get the data that caused the failure)? That would be the
> easiest thing for me.
Using two protocols on the same port is a definitly bad idea.
As you talk HTTP it is doable, since for both protocols, HTTP and SSL
the client speaks first, so that the server _might_ _guess_ based on
the first bytes sent whether or not SSL was wanted or not. And it is
not too difficult as the first bytes of SSL are non-printable codes while
the query of HTTP consists of printable characters.
With other protocols like SMTP, POP, IMAP this is not possible, because
here the server has to speak first. Now the server must wait to see, whether
the client sends a SSL hello or not, then maybe send the cleartext
server greeting. You already see the conflict!
Therefore it cannot be job of the OpenSSL library to include such
handshake heuristics, it would fail at on or the other occasion eventually.
Please implement this heuristic yourself. I don't know about the python
binding, but I would use BIO-pairs for this purpose. With BIO-pairs you
handle the data coming from/sent to the peer yourself, so you can decide
whether to send them through the SSL-engine or not.
Best regards,
Lutz
PS. Very knowledgable and experienced people spend a lot of time developing
protocols such that they are free of the deadlock-risks described above
and those protocols are updated to reflect the experiences made (check
the RFC archives). The best protocols are long lived and only carefully
extended like SMTP (20 years old and still alive :-).
--
Lutz Jaenicke [EMAIL PROTECTED]
BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
