On 03/04/15 20:48, Joris Van Remoortere wrote: > Hello, > > 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 > (http://en.wikipedia.org/wiki/Transport_Layer_Security#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. Matt
