[openssl-users] HTTP / HTTPS on same port
matt at openssl.org
Fri Apr 3 20:43:27 UTC 2015
On 03/04/15 20:48, Joris Van Remoortere wrote:
> I would like to ask your opinion and advice on accepting HTTP / HTTPS
> connections on the same port.
> I currently have a prototype that peeks at the first byte after
> accepting a new connection, and dispatches to the appropriate routines
> based on whether the first byte is 0x16 or not. This came from looking
> at the TLS handshake protocol
> and testing different libraries.
> The motivation for this was to avoid the configuration nightmare of
> introducing a second port, both in our code, and for administrators
> (firewall rules, etc.).
> 1) Is it valid to assume that the 1st byte of the handshake protocol is
> a valid way to disambiguate the traffic?
> 2) Are there any corner cases I might be missing?
There is a potential issue to consider if you were going to do it this
way. All modern clients will send 0x16 as the first byte of their
ClientHello. However this was not always the case, and you may encounter
some legacy clients that do not do this (for example OpenSSL 0.9.8
doesn't). Historically it was common to send SSLv2 backward compatible
ClientHellos - even if what is eventually negotiated is SSLv3 or above.
OpenSSL 0.9.8 will happily negotiate TLS1.0 by sending a SSLv2 backward
compatible ClientHello. Note this doesn't have anything to do with the
support for SSLv2 itself. Even servers which have disabled SSLv2 (which
is considered good practice), will usually accept this ClientHello
format (OpenSSL 1.0.2 does).
The first two bytes of the backward compatible format are the message
length. The most significant bit of the first byte is always set, so
this means you could conceivably receive anything from 0x80 or above, as
well as 0x16 as your first byte.
You may wish to look at how OpenSSL does protocol version detection to
help you. See the function ssl23_get_client_hello() in ssl/s23_srvr.c of
the OpenSSL 1.0.2 source code.
More information about the openssl-users