Amos Jeffries wrote:
On 14.03.2012 15:16, Henrik Nordström wrote:
ons 2012-03-14 klockan 14:18 +1300 skrev Amos Jeffries:
huh? it says exactly what protocol the tunnel is intended to contain
(switch to).
On GET/OPTIONS yes, but only for the transport, not tunnel.
You can use Upgrade on CONNECT as well if you want. But it's for the
client<->proxy only and says nothing about the contents of the tunnel
requested by CONNECT.
CONNECT www.example.com:80 HTTP/1.1
Upgrade: TLS/1.0
Connection: Upgrade
instructs the proxy that the client wishes to have the client<->proxy
connection wrapped in TLS/1.0. If the proxy agrees it sends a HTTP/1.1
101 Switching Protol response and any further communication from that
point is wrapped in SSL client<->proxy, without changing the tunnel (it
may still be SSH, IMAP, SMTP or whatever).
Telling us a bump is needed to find out more.
The *inverse* of this is what I'm saying is significant. When TLS is
*not* present its clearly not going to be something we can ssl-bump.
Therefore skip the bumping and don't interfere.
The existence of SSL/TLS does not suffice for making a conclusion.
The tunnel can be used for SSL+SMTP, SSL+XMPP, SSL+anything.
I think Squid should do the following in the sslBump handler:
- Open socket. If error, close socket to the browser.
- possibly: go to the filters indicating the start of a CONNECT, a filter may
decide to BLOCK just based on the endpoint address.
- Initiate SSL/TLS handshake, if error, signal filters (preferably indicating
there is no SSL/TLS)
If the filter says "PASS", reopen a socket to have a clean tunnel
- If the SSL/TLS handshake is ok, do the certificate checking. If error, send
an erroneous certificate to the browser to give the end user a good idea of
what is going on.
- Verify that the server speaks SSL+HTTP, if not signal filters (preferably
indicating there is SSL/TLS but no HTTP)
- If the endpoint speaks SSL+HTTP, go to the filters, indicating a succesful
CONNECT to an SSL+HTTP endpoint.
For a bit of perspective: We could take a GET with Upgrade:, send it
unchanged to a peer and treat the resulting TCP connection as an
Upgraded tunnel over which native X traffic happens. No different to
handling a CONNECT today.
Clients may only send Upgrade together with Connection: Upgrade as it's
a hop-by-hop directive, so any proxying of the directive would
technically be a protocol violation.
We are asking an HTTP peer to Upgrade its hop. We have not sent
acceptance to the client, and will relay the peers reject/accept. No
violation there. We just loose control of a HTTP connection by trying is
all.
Amos
