Re: SSL and non-SSL connections on the same port
> 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. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: SSL and non-SSL connections on the same port
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]
RE: SSL and non-SSL connections on the same port
> 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. How could the OpenSSL library possibly determine whether or not a connection conformed to a protocol that it had no knowledge of? This has to be done above the SSL layer. DS __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: SSL and non-SSL connections on the same port
> > 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 > How could the OpenSSL library possibly determine whether or not a > connection conformed to a protocol that it had no knowledge of? This has to > be done above the SSL layer. I don't want it to tell me that, I just want it to tell me whether it's an SSL connection or not. However, Lutz's comment from before was correct. It's hard to do it for EVERY protocol, since some protocols require the server to speak first. It might even be impossible, because OpenSSL might actually SEND something to the client before realizing this isn't an SSL connection. So I'll have to open the openssl.org documentations (is it me, or is this site really really slow?), figure out how BIOs work, and try to get them to work from Python, too. On second thought, I think I'll settle for using two ports for now, unless someone has a cleaner way of doing it. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: SSL and non-SSL connections on the same port
On 10 Jan, Itay Zandbank wrote: > However, Lutz's comment from before was correct. It's hard to do it for > EVERY protocol, since some protocols require the server to speak first. It > might even be impossible, because OpenSSL might actually SEND something to > the client before realizing this isn't an SSL connection. A solution my be using OpenSSL as a state machine. Have a look at demos/state_machine or demos/tunala (currently only in the CVS repository). With this technic you have the data from the socket in a buffer where you can inspect it, if it is encrypted or not. Then you process it normal, if it is unencrypted. Or you have to feed it to OpenSSL via memory BIOs, if it is encrypted. -- tschüß, Jochen Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/ __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: SSL and non-SSL connections on the same port
[EMAIL PROTECTED] writes: > On 10 Jan, Itay Zandbank wrote: > > > However, Lutz's comment from before was correct. It's hard to do it for > > EVERY protocol, since some protocols require the server to speak first. It > > might even be impossible, because OpenSSL might actually SEND something to > > the client before realizing this isn't an SSL connection. > A solution my be using OpenSSL as a state machine. Have a look at > demos/state_machine or demos/tunala (currently only in the CVS > repository). With this technic you have the data from the socket in a > buffer where you can inspect it, if it is encrypted or not. Then you > process it normal, if it is unencrypted. Or you have to feed it to > OpenSSL via memory BIOs, if it is encrypted. This only works if you understand what the protocol is that is the alternative to SSL. Imagine that the alternatives are SSL and some protocol that we'll call X. Now, X is designed so that the first X message looks exactly like part of an SSLv3 ClientHello. So, when you read the first packet off the wire, it might contain a full X PDU or it might contain only part of an SSLv3 PDU with more to come. Which is it? We don't know and there's no good way to determine. Now, certain protocols DON'T have this property. For instance, it's possible to distinguish between SSLv2 and SSLv3 PDUs. If you're dealing with such a protocol, you might have a fighting chance at doijng what you describe. -Ekr __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: SSL and non-SSL connections on the same port
On Wed, Jan 10, 2001 at 10:55:46AM +0200, Itay Zandbank wrote: > 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. In M2Crypto.SSL.Connection, line 173: def makefile(self, mode='rb', bufsize='ignored'): # XXX Need to dup(). return BIO.IOBuffer(BIO.BIO(self.sslbio), mode) The 'ignored' default parameter and "XXX" in the comment intimates this bit really needs improvement, but this method does turn an SSL socket into a buffering BIO which is made available to you as a Python file-like object. Cheers. -- Ng Pheng Siong <[EMAIL PROTECTED]> * http://www.post1.com/home/ngps __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: SSL and non-SSL connections on the same port
On 11 Jan, Holger Reif wrote:
> With regard to HTTP/HTTPS, a look into the mod_ssl sources
> available from www.modssl.org might worth a look. There is
> this feature implemented.
I had some looks into mod_ssl when I integrated SSL in thttpd. It uses
somthing like
if ( ERR_GET_REASON( ERR_peek_error( )) == SSL_R_HTTP_REQUEST ) {
if SSL_accept() fails. This is the way I used in thttpd.
--
tschüß,
Jochen
Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
RE: SSL and non-SSL connections on the same port
> > > 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 > > How could the OpenSSL library possibly determine whether or not a > > connection conformed to a protocol that it had no knowledge of? This has > > to be done above the SSL layer. > I don't want it to tell me that, I just want it to tell me > whether it's an SSL connection or not. I'm afraid that's impossible. There is no definitive test you can use that can determine whether something is an SSL connection or "not" without knowing what the alternative is. > However, Lutz's comment from before was correct. It's hard to do it for > EVERY protocol, since some protocols require the server to speak first. It > might even be impossible, because OpenSSL might actually SEND something to > the client before realizing this isn't an SSL connection. It is impossible. Without knowing what the other protocol is, there's no way to know what distinguishes it from SSL. Let's try a commonsense example. You can easily craft a rule for telling whether something is an apple or a pear, but can you craft a simple rule to tell if something is an apple or "not" without knowing what the "not" might be? Try it. This is what you are asking the OpenSSL library to do. DS __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
