Thank you, this is very helpful information. I will look into these options. I know this question will make some people cringe, but the following crazy thought has been bothering me: Instead of generating a spoofed cert for every domain, why can't squid serve out one wildcard cert for each root domain. eg *.com? I know this sounds crazy but once we're breaking ssl and the client has to trust us, is there any reason this can't be done? Seems to me it would simplify a lot of the edge cases at the same time reduce overhead. (eg it would solve the SNI problem at gmail.com) To take it further there could even be one cert which includes SubjectAltName wildcards for all the popular root domains.. I'm sure there's a good reason this hasn't been done just wondering if someone could set me straight. :-) Thanks. On Mon, Jun 16, 2014 at 12:26 PM, Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > On 06/15/2014 12:31 PM, Douglas Davenport wrote: > >> Interesting, I thought bump server first solved this type of problem. > > In server-first bumping, Squid just mimics whatever certificate the > server responds with. If the server responds with the "wrong" > certificate, Squid mimics that. > > >> I wonder how is google serving different certs for gmail.com vs >> mail.google.com at the same IP is this SNI. Is that something squid is >> likely to support one day? > > It sounds like SNI could indeed be involved here. IIRC, > bump-server-first does not forward SNI to the origin server because > Squid does not know the client SNI at server bumping time. > > Consider trying SSL Peek and Splice. I am not 100% sure it forwards SNI > today, but that feature builds the necessary [complex!] infrastructure > to do so: http://wiki.squid-cache.org/Features/SslPeekAndSplice > > > HTH, > > Alex. > > > >>> On 06/13/2014 09:56 PM, Douglas Davenport wrote: >>>> >>>> I have squid 3.3.10 setup with sslbump working for all sites except >>>> when a user tries to type in gmail.com. For some reason the browser >>>> complains about certificate name mismatch. On examination the >>>> generated cert is actually for mail.google.com. Apparently google is >>>> redirecting buy why does this error happen only with sslbump. Anyone >>>> else have this issue, workarounds? >>>> >>>> Thanks in advance! >>>> >>> >
