On 26/06/18 01:56, Gordon Hsiao wrote: > On 25/06/18 14:59, Gordon Hsiao wrote: > > On 25/06/18 05:15, Gordon Hsiao wrote: > > > at https://wiki.squid-cache.org/SquidFaq/OrderIsImportant I > noticed > > > redirectors are way ahead of ssl-bump in the callout order, in a > > > https-ssl-bump case > > > > There is not really any "https-ssl-bump" case. > > > > There is SSL-Bump (decrypting a TLS stream - or not), and > there is HTTPS > > (HTTP messages inside TLS). > > > > > > > you will need ssl-bump to run (so you can get full > > > URL for example), then you can run redirector based on the > result of > > > ssl-bump, correct? > > > > No. SSL-Bump is an operation applied to a CONNECT message, > when setting > > up the TLS tunnel. There are maybe also *multiple* CONNECT > messages when > > SSL-Bump gets involved - which the FAQ text following that > sequence > > describes. > > > > > > HTTP is stateless protocol. So the CONNECT message(s) are > independent of > > both each other, and anything decrypted from inside the > tunnel. Each and > > every message Squid handles gets its own cycle through the callout > > sequence. > > > > > > > why is redirector run before ssl-bump? > > > > Because Squid needs to know _where_ it is going before it can > connect > > there. SSL-Bump is part of tunnel/connection setup. > > > > Amos > > > > > > will SSL-Bump(not 'peek+splice', but the 'peek+bump' mode) decrypt all > > the tcp packets? For example I connect to youtube.com/myvideo > <http://youtube.com/myvideo> > > <http://youtube.com/myvideo>, will peek+bump only decrypt the pseudo > > CONNECT messages(I'm doing transparent proxy), or will it decrypt all > > the video streams too? if it's the latter case the proxy will be cpu > > intensive. > > Sorry if I wasn't clear. The ssl_bump (directive and CONNECT handling) > part is the TLS handshake at the beginning of TLS connections. Once the > decrypt or splice is setup it just continues indefinitely. Whatever is > being decrypted from within that TLS is completely separate from the > bumping itself. > > Amos > > > So, peek+bump itself will only deal with TLS handshake part(e.g. to get > FQDN/full-URL for redirectors) Using the correct terms helps understanding. see RFC 7230 <https://tools.ietf.org/html/rfc7230#section-5.3> 'peek' and 'bump' are actions the SSL-Bump feature does. * SSL-Bump 'peek' action gives the TLS SNI. Which is *only* a domain name / FQDN - so an authority-form URI (FQDN:port) is known for the server. * SSL-Bump 'bump' action exposes the encrypted requests which contain their own URI-scheme, domain, port, path, query etc. - so the full absolute-form URI is known for each decrypted message. - these may not match the authority-form URI from the CONNECT message. >, still the proxy will have to do > aes-decrypt-and-encrypt for the same TCP stream when peek+bump is used, To get full-URL (ie path and query parts). > which could be very cpu intensive, correct? Because once peek+bump is > used, the proxy split the ssl stream into two segments and will have to > deal with everything for both ends. Yes. > > peek+splice is totally different and it will not need the > aes-decrypt-and-encrypt, basically just probe for SNI then tunnel the > whole connection, so proxy's cpu should not be overloaded at all. Close yes. Though to complicate things the presence of a proxy at all splits the stream into "two parts" to get that peek ability. It's just that splice action afterwards avoids the decrypt+encrypt CPU cycles. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
