Hi,
Below is Mike's reply to Smith about the CUPS approach to "sniffing"
incoming connections (for TLS Client Hello versus HTTP requests).
Cheers,
- Ira
---------- Forwarded message ----------
From: Michael Sweet <msweet at apple.com>
Date: Mon, Mar 3, 2014 at 9:14 AM
Subject: Re: ipps port scheme
To: "Kennedy, Smith (Wireless Architect)" <smith.kennedy at hp.com>
Cc: Ira McDonald <blueroofmusic at gmail.com>
[Apologies if this is my second response to this; I seem to remember
replying but can't find a copy of it...]
Smith,
CUPS has a simple check for a valid HTTP
DELETE/GET/HEAD/OPTIONS/POST/PUT/TRACE request line after we accept a
connection. This is the same strategy that the Samba project uses, BTW...
The code in question is:
#ifdef HAVE_SSL
if (con->auto_ssl)
{
/*
* Automatically check for a SSL/TLS handshake...
*/
con->auto_ssl = 0;
if (recv(httpGetFd(con->http), buf, 1, MSG_PEEK) == 1 &&
(!buf[0] || !strchr("DGHOPT", buf[0])))
{
/*
* Encrypt this connection...
*/
cupsdLogClient(con, CUPSD_LOG_DEBUG2,
"Saw first byte %02X, auto-negotiating "
"SSL/TLS session.", buf[0] & 255);
if (cupsd_start_tls(con, HTTP_ENCRYPTION_ALWAYS))
cupsdCloseClient(con);
return;
}
}
#endif /* HAVE_SSL */
A more "complete" implementation might actually look for an SSL or TLS
ClientHello header (the first several bytes are fairly stable), but at the
time I felt that a) it was more likely that the TLS header would change
than the HTTP header and b) the SSL libraries are better capable of
validating the ClientHello than we are.
Also, the above code does not support non-conforming HTTP clients that send
anything other than a HTTP request line or TLS ClientHello. Sending
whitespace or other non-conforming crap is explicitly not supported and, in
all the years that CUPS has been around, never been necessary to
interoperate with any web browser or IPP client.
On Feb 27, 2014, at 3:32 PM, Kennedy, Smith (Wireless Architect) <
smith.kennedy at hp.com> wrote:
Hi there,
Some of our firmware folks have been thrashing with how to support
connections for both "ipp:" (conventional IPP) and "ipps:" (IPP over TLS)
with one listener on port 631, as described in "IPP over HTTPS and 'ipps'
URI Scheme". I am not involved with this at all, but I thought I would
pass this on and see if there were any recommendations you could offer as
far as how this would be done, using BSD sockets. I don't know if there
are boilerplate examples of how to do this generally on the web, but I will
search for that as well. If there was some way to provide an example of
that in an annex to this document such an addition could be useful to get
people past their skepticism.
I've got some feedback on the "IPP over HTTPS and 'ipps' URI Scheme" spec
as well, that came out of this. I will post that feedback to the reflector
for the sake of posterity.
Thanks for any help!
Smith
/**
Smith Kennedy
ATB Wireless Architect - PPS
Hewlett-Packard Co.
*/
Begin forwarded message:
in typical BSD socket working with openssl, FW performs a SSL_accept()
immediately after the BSD accept(). There is no parsing/voting mechanism to
detect the nature of the incoming data.
It is how https works.
If 'ipps' uses the same port as 'ipp', it can't use the same connection and
ssl negotiation pattern than https. So a few questions come to mind:
1. Does ipps mean that first bytes of data exchanged between client
and server are SSL packets?
2. Or does it mean that the first exchange is plaintext http traffic
but the two parties can negotiate a 'HTTP 101 Upgrade: TLS' later?
If #1, how does ipp advertise #2?
Let me just say that if ipp rely on a preparsing/voting mechanism often
leads to complexity. Best case scenario is: if the first 4 bytes are ascii
'POST' then http else ssl. However, this is never this easy, in fact our
current http server parses the incoming payload to filter garbage
characters (null, white space, tab, etc...).
Also, I'm not sure how off-the-shelf stacks (nginx) would handle this
pattern.
_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20140303/946d0159/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4881 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/ipp/attachments/20140303/946d0159/attachment.p7s>