<div dir="ltr"><span class="gmail-im" style="font-size:12.800000190734863px"><p class="gmail-m_-2984887475346603915gmail-m_5450373487460874020MsoListParagraph" style="margin:0in 0in 0.0001pt 0.5in;font-size:11pt;font-family:Calibri,sans-serif"><i>Thanks for the quick reply. I want to explain my question further.<u></u><u></u></i></p><p class="gmail-m_-2984887475346603915gmail-m_5450373487460874020MsoListParagraph" style="margin:0in 0in 0.0001pt 0.5in;font-size:11pt;font-family:Calibri,sans-serif"><i>Consider C1 and S1 connections were created for a HTTPs connection using ssl-bump. C1 has been served and closed from the client side.<u></u><u></u></i></p><p class="gmail-m_-2984887475346603915gmail-m_5450373487460874020MsoListParagraph" style="margin:0in 0in 0.0001pt 0.5in;font-size:11pt;font-family:Calibri,sans-serif"><i>Now, the client initiates another HTTPS connection, C2. Since, persistent connection is enabled, expectation is to see that S1 gets re-used.<u></u><u></u></i></p><p class="gmail-m_-2984887475346603915gmail-m_5450373487460874020MsoListParagraph" style="margin:0in 0in 0.0001pt 0.5in;font-size:11pt;font-family:Calibri,sans-serif"><i>Behaviour seen now is that S2 gets created and a handshake ensues between squid and server. After ~30seconds, S1 is re-used to serve the<u></u><u></u></i></p><p class="gmail-m_-2984887475346603915gmail-m_5450373487460874020MsoListParagraph" style="margin:0in 0in 0.0001pt 0.5in;font-size:11pt;font-family:Calibri,sans-serif"><i>request C2. Persistence seems to work since S1 is re-used. However, why was S2 initiated and why was S1 re-used after ~30seconds?</i></p><p class="gmail-m_-2984887475346603915gmail-m_5450373487460874020MsoListParagraph" style="margin:0in 0in 0.0001pt 0.5in;font-size:11pt;font-family:Calibri,sans-serif"><i><br></i></p></span><p class="gmail-m_-2984887475346603915gmail-m_5450373487460874020MsoListParagraph" style="font-size:12.800000190734863px;margin:0in 0in 0.0001pt 0.5in"><b><i style="font-family:Calibri,sans-serif;font-size:11pt">PFA: p</i><font face="Calibri, sans-serif"><span style="font-size:14.666666984558105px"><i>cap</i></span></font><i style="font-family:Calibri,sans-serif;font-size:11pt"> file and the squid.conf</i></b></p></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 2, 2018 at 4:57 PM, Alex Rousskov <span dir="ltr"><<a href="mailto:rousskov@measurement-factory.com" target="_blank">rousskov@measurement-factory.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 07/02/2018 05:34 PM, Vishali Somaskanthan wrote:<br>
<br>
> I am trying out SSL Bump for my connections from Squid to server and<br>
> trying to put along server persistent connections as well. I would like<br>
> to know how squid behaves with both of these turned on??<br>
<br>
</span>In modern Squids, all(*) bumped SSL client HTTP requests (from client<br>
connection C) should use the corresponding bumped connection to the<br>
server (S). After the first HTTP request, if more requests arrive on<br>
connection C, and they are all regular/basic requests, then they can all<br>
go through connection S. Once HTTP rules, timeouts, or other factors<br>
prohibit connection S or connection C reuse, Squid should close both<br>
connections.<br>
<br>
Please note that I do not know whether Squid correctly forces all(*)<br>
HTTP requests on connection C to connection S, but it should. If it does<br>
not, file a bug report. Same for closing connection C when connection S<br>
becomes unusable.<br>
<span class=""><br>
<br>
> I see info in the squid wiki page that SSL Bump creates fake CONNECT<br>
> requests and Peeking at Step1 creates another CONNECT request. <br>
<br>
</span>Peeking or staring may indeed produce internal fake CONNECT requests,<br>
but they are unrelated to your question. They are used internally to<br>
handle the client TLS connection and for giving adaptation services a<br>
say in the matter. Persistency is an HTTP term that is applied to what<br>
happens _after_ the TLS connections is bumped.<br>
<br>
(Also, peeking is a part of the SslBump feature -- they are not two<br>
different actions or stages as "and" in your summary implies).<br>
<br>
<br>
HTH,<br>
<br>
Alex.<br>
P.S. (*) "all" should be interpreted as "all that need a server<br>
connection" here -- pure cache hits, adaptation-satisfied requests, and<br>
probably some erroneous requests (e.g., those blocked by http_access<br>
rules?) do not use the server connection.<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Regards,</div>Vishali Somaskanthan</div></div>
</div>