[squid-dev] [PATCH] Fast SNI peek

[Eliezer Croitoru]

Hey Alex,

I have a question about this specific file and SNI peek and splice in general.
For the scenario which the SNI declares www.google.com and the destination IP address is not the domain, IE default apache or any other domain. What happens? And specifically about the request splicing?
And in more detail my concern is that if some software will fake the SNI knowing that the destination will never be the requested one but some default of another domain, will the request be spliced anyway?
I am not sure what squid does now and if something might be changed or not.
I do believe that more then one admin will want to enforce dns resolution policy on such requests and to decide what to do with "rough" requests.

Eliezer

----
Eliezer Croitoru
Linux System Administrator
Mobile: +972-5-28704261
Email: eliezer at ngtech.co.il


-----Original Message-----
From: squid-dev [mailto:squid-dev-bounces at lists.squid-cache.org] On Behalf Of Alex Rousskov
Sent: Friday, May 13, 2016 11:38 PM
To: Squid Developers
Subject: Re: [squid-dev] [PATCH] Fast SNI peek

On 05/13/2016 11:07 AM, Christos Tsantilas wrote:

> mode | trunk | fast-sni
> SS1     100%     100%
> SS2      22%      69%
> SS3      16%      26%

The above [slightly adjusted by me] table needs an explanation and a few disclaimers.

SSN in the first column means "splicing at SslBump stepN". That is, we have tested recent trunk and fast-sni branch code using these three SslBump configurations:

  # SS1 (baseline):
  ssl_bump splice all

  # SS2 (peek at SNI -- the focus of this project):
  ssl_bump peek step1
  ssl_bump splice all

  # SS3 (peek at SNI then peek at the server certificate):
  ssl_bump peek step1
  ssl_bump peek step2
  ssl_bump splice all

The percentage shown is "Squid performance" compared to SS1/baseline where no peeking is performed. Higher numbers are better.

For example, the SS2 test shows that trunk SNI peeking performance is only about 20% of the "immediately splice everything without peeking"
baseline. In other words, trunk wastes ~80% of performance on SNI peeking. The optimized version loses only about 30%, approaching 70% of "ideal" performance.

Please note that SS3 includes certificate validation so it is not an estimate of step1+2 peeking performance alone; there were even DNS requests during step3 in our rough tests. This could be perfected further, but since our focus is on SNI peeking (SS2), we did not polish.
The significant overheads of those additional activities probably explain why make SS3 trunk and fast-sni performance do not differ as much as performance during SS2.

Absolute performance of trunk and fast SNI branch during SS1 tests was about the same, so 100% baseline is the same for both code flavors and all the reported percentages can be compared with each other.

These results are based on a micro-test using a best-effort Polygraph workload (i.e., each Polygraph robot is configured to send the next requests only after getting a response to the previous one). There were
1000 robots and 1000 origin servers during these tests. We minimized irrelevant activity by sending only HTTPS HEAD requests and intercepting SSL traffic (i.e., no CONNECTs). We are publishing percentages and not absolute request rates or response times that do not estimate true sustained performance in a realistic environment due to these simplifications. Suffice to say that Squid was doing more than 1000 HTTPS requests per second in all these tests.

The results Christos shared did not come from the very last version of trunk (currently untestable anyway) and fast SNI branches, but they should be within a few percentage points of the latest code.


Cheers,

Alex.

_______________________________________________
squid-dev mailing list
squid-dev at lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev