<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
-----BEGIN PGP SIGNED MESSAGE----- <br>
Hash: SHA1 <br>
<br>
As I can see, we have two major problems with SSL Bump now.<br>
<br>
1. Stupid apps and it's stupid developers - like ICQ and other
stupid IM - which is hope 443 port is never be blocked due to using
for logons/internet banking etc.<br>
This stupid way broke standards (?) and make us crazy. Now single
solution is catch them manually and pass it without bumping. This is
the simplest problem. And I hope it will be solved in core - i.e. in
Squid directly.<br>
<br>
2. SSL Pinned sites. We cannot do with them anything excluding sniff
it and pass by IP without bump.<br>
<br>
First problems seems to solve easy. Either by helper, or by squid -
no matter. It's really simple. Just check SSL cert on server side -
and make decision - to bump, or not to bump.<br>
<br>
The second problem seems difficult and now I can't see any
reasonable solution, excluding sniffer/manual add to acl.<br>
<br>
Any ideas? Will be write helper?<br>
<br>
WBR, Yuri<br>
<br>
05.01.2015 2:17, Douglas Davenport пишет:<br>
<span style="white-space: pre;">> I saw a very similar feature in
ufdbGuard which is a URL filter implemented as a Squid Redirector.
They have a feature which probes the destination server for a
valid HTTPS cert in parallel to the user's connection and
terminates it if it turns out not to be a valid HTTPS cert. Their
code is open source, maybe this could be helpful in creating such
a helper?<br>
><br>
> <a class="moz-txt-link-freetext" href="http://www.urlfilterdb.com/home.html">http://www.urlfilterdb.com/home.html</a><br>
><br>
> On Sat, Jan 3, 2015 at 3:45 AM, Yuri Voinov
<<a class="moz-txt-link-abbreviated" href="mailto:yvoinov@gmail.com">yvoinov@gmail.com</a> <a class="moz-txt-link-rfc2396E" href="mailto:yvoinov@gmail.com"><mailto:yvoinov@gmail.com></a>> wrote:<br>
><br>
><br>
> Term "HTTPS" often uses as "Any connect over 443 port"....<br>
><br>
> 03.01.2015 13:59, Jason Haar пишет:<br>
> > On 01/01/15 00:11, James Harper wrote:<br>
> >> The helper connects to the IP:port and tries to
obtain the<br>
> certificate, and then caches the result (in an sqlite
database). If it<br>
> can't do so within a fairly short time it returns failure
(but keeps<br>
> trying a bit longer and caches it for next time).
Alternatively if the<br>
> IP used to be SSL but is now timing out it returns the
previously cached<br>
> value. Negative results are cached for an increasing amount
of time each<br>
> time it fails, on the basis that it probably isn't SSL.<br>
> > That sounds great James! I'd certainly like to take a
look at it too<br>
><br>
> > However, you say "SSL" - did you mean "HTTPS"? ie
discovering a ip:port<br>
> > is a IMAPS server doesn't really help squid talk to it -
surely you want<br>
> > to discover HTTPS servers - and everything else should
be<br>
> > pass-through/splice?<br>
><br>
><br>
><br>
> _______________________________________________<br>
> squid-users mailing list<br>
> <a class="moz-txt-link-abbreviated" href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.org</a>
<a class="moz-txt-link-rfc2396E" href="mailto:squid-users@lists.squid-cache.org"><mailto:squid-users@lists.squid-cache.org></a><br>
> <a class="moz-txt-link-freetext" href="http://lists.squid-cache.org/listinfo/squid-users">http://lists.squid-cache.org/listinfo/squid-users</a><br>
><br>
></span><br>
<br>
-----BEGIN PGP SIGNATURE-----
<br>
Version: GnuPG v2
<br>
<br>
iQEcBAEBAgAGBQJUqbC7AAoJENNXIZxhPexGwwkH/j8XR2fQ4v/r3M2zFuDuhVsP
<br>
JZMM93IvZrGYRzJjAmmwg7ZUoYdwWWEaXoY6GygO+RdZESWfPvh00cSsxwRKfmvm
<br>
2s7sLDKlPnfUsf9fyWnihCtJg9hETZTsvUqK9I+iopiM1DHq/qwX3Pjkb2e2T45u
<br>
JuqU5ySBZPEt6G1gRn/+F2EyHdhWpa9OOtfeTAt4/oaJIuLoHP7855fif/1eg59U
<br>
QlISZkLjDcL4DqEVM+9UJh9TSN+dawj/Ks+3b+MT8sA/xvVdOyqhLMqnm4MPadSv
<br>
yvK5nQWW4rkfHOJ1zwWq3hAMLjCIXjY4q1NxNQAxdK5ESZvszecvXg3JMKo/THw=
<br>
=Ygen
<br>
-----END PGP SIGNATURE-----
<br>
<br>
</body>
</html>