<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 25/06/18 14:59, Gordon Hsiao wrote:<br>
>      On 25/06/18 05:15, Gordon Hsiao wrote:<br>
>     > at <a href="https://wiki.squid-cache.org/SquidFaq/OrderIsImportant" rel="noreferrer" target="_blank">https://wiki.squid-cache.org/SquidFaq/OrderIsImportant</a> I noticed<br>
>     > redirectors are way ahead of ssl-bump in the callout order, in a<br>
>     > https-ssl-bump case<br>
> <br>
>     There is not really any "https-ssl-bump" case.<br>
> <br>
>     There is SSL-Bump (decrypting a TLS stream - or not), and there is HTTPS<br>
>     (HTTP messages inside TLS).<br>
> <br>
> <br>
>     > you will need ssl-bump to run (so you can get full<br>
>     > URL for example), then you can run redirector based on the result of<br>
>     > ssl-bump, correct?<br>
> <br>
>     No. SSL-Bump is an operation applied to a CONNECT message, when setting<br>
>     up the TLS tunnel. There are maybe also *multiple* CONNECT messages when<br>
>     SSL-Bump gets involved - which the FAQ text following that sequence<br>
>     describes.<br>
> <br>
> <br>
>     HTTP is stateless protocol. So the CONNECT message(s) are independent of<br>
>     both each other, and anything decrypted from inside the tunnel. Each and<br>
>     every message Squid handles gets its own cycle through the callout<br>
>     sequence.<br>
> <br>
> <br>
>     > why is redirector run before ssl-bump?<br>
> <br>
>     Because Squid needs to know _where_ it is going before it can connect<br>
>     there. SSL-Bump is part of tunnel/connection setup.<br>
> <br>
>     Amos<br>
> <br>
> <br>
> will SSL-Bump(not 'peek+splice', but the 'peek+bump' mode) decrypt all<br>
> the tcp packets? For example I connect to <a href="http://youtube.com/myvideo" rel="noreferrer" target="_blank">youtube.com/myvideo</a><br>
> <<a href="http://youtube.com/myvideo" rel="noreferrer" target="_blank">http://youtube.com/myvideo</a>>, will peek+bump only decrypt the pseudo<br>
> CONNECT messages(I'm doing transparent proxy), or will it decrypt all<br>
> the video streams too? if it's the latter case the proxy will be cpu<br>
> intensive.<br>
<br>
Sorry if I wasn't clear. The ssl_bump (directive and CONNECT handling)<br>
part is the TLS handshake at the beginning of TLS connections. Once the<br>
decrypt or splice is setup it just continues indefinitely. Whatever is<br>
being decrypted from within that TLS is completely separate from the<br>
bumping itself.<br>
<br>
Amos<br>
<br><br></blockquote><div>So, peek+bump itself will only deal with TLS handshake part(e.g. to get FQDN/full-URL for redirectors) , still the proxy will have to do aes-decrypt-and-encrypt for the same TCP stream when peek+bump is used, 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.</div><div><br></div><div>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.</div><div><br></div><div>Thanks a lot for the explanations,</div><div><br></div><div>Gordon</div></div></div>