attachment
<div dir="ltr"><div><div><div><div>Hi,<br><br></div>Below is Mike's reply to Smith about the CUPS approach to "sniffing"<br></div>incoming connections (for TLS Client Hello versus HTTP requests).<br><br></div>
Cheers,<br></div>- Ira<br><br clear="all"><div><div><div><div><div><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Michael Sweet</b> <span dir="ltr"><<a href="mailto:msweet@apple.com">msweet@apple.com</a>></span><br>
Date: Mon, Mar 3, 2014 at 9:14 AM<br>Subject: Re: ipps port scheme<br>To: "Kennedy, Smith (Wireless Architect)" <<a href="mailto:smith.kennedy@hp.com">smith.kennedy@hp.com</a>><br>Cc: Ira McDonald <<a href="mailto:blueroofmusic@gmail.com">blueroofmusic@gmail.com</a>><br>
<br><br><div style="word-wrap:break-word"><div>[Apologies if this is my second response to this; I seem to remember replying but can't find a copy of it...]</div><div><br></div>Smith,<div><br></div><div>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:</div>
<div><br></div><div><div> #ifdef HAVE_SSL</div><div> if (con->auto_ssl)</div><div> {</div><div> /*</div><div> * Automatically check for a SSL/TLS handshake...</div><div> */</div><div><br></div><div>
con->auto_ssl = 0;</div><div><br></div><div> if (recv(httpGetFd(con->http), buf, 1, MSG_PEEK) == 1 &&</div><div> (!buf[0] || !strchr("DGHOPT", buf[0])))</div><div> {</div>
<div>
/*</div><div> * Encrypt this connection...</div><div> */</div><div><br></div><div> cupsdLogClient(con, CUPSD_LOG_DEBUG2,</div><div> "Saw first byte %02X, auto-negotiating "</div>
<div> <span style="white-space:pre-wrap"> </span> "SSL/TLS session.", buf[0] & 255);</div><div><br></div><div> if (cupsd_start_tls(con, HTTP_ENCRYPTION_ALWAYS))</div><div> cupsdCloseClient(con);</div>
<div><br></div><div> return;</div><div> }</div><div> }</div><div> #endif /* HAVE_SSL */</div><div><br></div></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div><br></div><div><div><div class="h5"><div><div>On Feb 27, 2014, at 3:32 PM, Kennedy, Smith (Wireless Architect) <<a href="mailto:smith.kennedy@hp.com" target="_blank">smith.kennedy@hp.com</a>> wrote:</div>
<br><blockquote type="cite"><div style="word-wrap:break-word">Hi there,<div><br></div><div>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.</div>
<div><br></div><div>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.</div><div><br></div><div>
Thanks for any help!</div><div><br><div>
<div style="font-family:Arial;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word">
Smith<br><br>/**<br> Smith Kennedy<br> ATB Wireless Architect - PPS<br> Hewlett-Packard Co.<br>*/<br><br><br></div>
</div>
<div><br><div>Begin forwarded message:</div><br><blockquote type="cite"><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><span> </span>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.<u></u><u></u></span></div>
<div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">It is how https works.<u></u><u></u></span></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> </span></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">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:<u></u><u></u></span></div>
<div style="margin:0in 0in 0.0001pt 0.5in;font-size:12pt;font-family:'Times New Roman',serif;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-transform:none;white-space:normal;word-spacing:0px">
<span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><span>1.<span style="font-style:normal;font-variant:normal;font-weight:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'"> <span> </span></span></span></span><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Does ipps mean that first bytes of data exchanged between client and server are SSL packets?<u></u><u></u></span></div>
<div style="margin:0in 0in 0.0001pt 0.5in;font-size:12pt;font-family:'Times New Roman',serif;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-transform:none;white-space:normal;word-spacing:0px">
<span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><span>2.<span style="font-style:normal;font-variant:normal;font-weight:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'"> <span> </span></span></span></span><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Or does it mean that the first exchange is plaintext http traffic but the two parties can negotiate a ‘HTTP 101 Upgrade: TLS’ later?<u></u><u></u></span></div>
<div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> </span></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">If #1, how does ipp advertise #2?<u></u><u></u></span></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> </span></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">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…).<u></u><u></u></span></div>
<div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Also, I’m not sure how off-the-shelf stacks (nginx) would handle this pattern.</span></div></blockquote></div><br></div></div></blockquote>
</div>
<br></div></div><div>
<span style="border-collapse:separate;font-family:'Andale Mono';border-spacing:0px"><span style="text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;text-transform:none;white-space:normal;font-family:'Andale Mono';word-spacing:0px"><div style="word-wrap:break-word">
_________________________________________________________<br>Michael Sweet, Senior Printing System Engineer, PWG Chair</div></span></span>
</div>
<br></div></div></div><br></div></div></div></div></div></div>