Re: [openssl-users] HTTP / HTTPS on same port
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Salz, Rich Sent: Friday, April 03, 2015 15:55 To: openssl-users@openssl.org Subject: Re: [openssl-users] HTTP / HTTPS on same port It is a hack. That's debatable. What's so sacred about separating traffic by port? Valid TLS traffic and valid plaintext HTTP traffic are distinguishable - there aren't any ambiguous cases. Most people do it the other way and look for a G or P as the first letter. Now *that* is a hack. And wrong, and broken. Looking at the first few bytes to see if they're 1) ASCII uppercase letters and 2) form the prefix of a valid HTTP command would be satisfactory. -- Michael Wojcik Technology Specialist, Micro Focus This message has been scanned for malware by Websense. www.websense.com ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] HTTP / HTTPS on same port
It is a hack. Most people do it the other way and look for a G or P as the first letter. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] HTTP / HTTPS on same port
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 ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] HTTP / HTTPS on same port
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? 3) Are there any security reasons for not doing this? Thanks for your advice, Joris ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] HTTP / HTTPS on same port
Hi,
I suggested one such implementation in mongoose opensource web server
You can check it in .
https://groups.google.com/forum/#!msg/mongoose-users/IAzYHF0do-I/INc_VmLAe6gJ
This is the function I added
let me know if it is useful.
static int CheckSSL(int nSocket)
{
/* taken from s23_svr.c int ssl23_get_client_hello(SSL *s) of openssl */
char szData [12] ;
int nRet = 0 ;
int n;
memset ( szData, 0, sizeof(szData));
n = recv ( nSocket, szData, 11, MSG_PEEK ) ;
if (n 2)
{
if((szData[0] 0x80) (szData[2] == 1)) // SSL2_MT_CLIENT_HELLO
{
// SSLv2
nRet = 1;
}
else if(n 9)
{
if ((szData[0] == 22 ) // SSL3_RT_HANDSHAKE
(szData[1] == 0x03) // SSL3_VERSION_MAJOR
(szData[5] == 1) // SSL3_MT_CLIENT_HELLO
((szData[3] == 0 szData[4] 5)
|| (szData[9] == szData[1])))
{
// SSLv3
nRet = 1;
}
}
}
return nRet;
}
On Sat, Apr 4, 2015 at 5:10 AM, James Cloos cl...@jhcloos.com wrote:
JR == Joris Van Remoortere jo...@mesosphere.io writes:
JR I would like to ask your opinion and advice on accepting HTTP / HTTPS
JR connections on the same port.
IPP support both w/ and w/o tls on port 631.
Cups handles it like this:
http://www.pwg.org/archives/ipp/2014/017906.html
-JimC
--
James Cloos cl...@jhcloos.com OpenPGP: 0x997A9F17ED7DAEA6
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] HTTP / HTTPS on same port
JR == Joris Van Remoortere jo...@mesosphere.io writes: JR I would like to ask your opinion and advice on accepting HTTP / HTTPS JR connections on the same port. IPP support both w/ and w/o tls on port 631. Cups handles it like this: http://www.pwg.org/archives/ipp/2014/017906.html -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 0x997A9F17ED7DAEA6 ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] HTTP / HTTPS on same port
On 03/04/2015 22:12, Michael Wojcik wrote:
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
Of Salz, Rich
Sent: Friday, April 03, 2015 15:55
To: openssl-users@openssl.org
Subject: Re: [openssl-users] HTTP / HTTPS on same port
It is a hack.
That's debatable. What's so sacred about separating traffic by port? Valid TLS
traffic and valid plaintext HTTP traffic are distinguishable - there aren't any
ambiguous cases.
Most people do it the other way and look for a G or P as the first letter.
Now *that* is a hack. And wrong, and broken. Looking at the first few bytes to
see if they're 1) ASCII uppercase letters and 2) form the prefix of a valid
HTTP command would be satisfactory.
Actually, I would code any HTTP request parser to accept
lower case,even if I would code request generators to
issue the standard request keywordsin uppercase only
(as required by the spec). Basic Postel principle
in action, really.
Additionally the HTTP/1.1 spec (RFC2616) explicitly
allows future method namesto contain any US-ASCII
char except control chars (0x00..0x1F), space (0x20)
and the following separators: ()@,;:\\\/[]?={},
see RFC2616 section 5.1.1 which references the
definitions of token and CHAR in section 2.2.
In the updated HTTP/1.1 spec (RFC7230 et.seq.),
the equivalent rules are in RFC7230 section 3.1.1
with token and tchar defined in section 3.2.6 .
Another possibility for HTTP and HTTPS on the same
port is to implement RFC2817, which specifies a way
to use a HTTP request to switch a connection to HTTPS.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
