nanog mailing list archives
Re: HTTPS redirects to HTTP for monitoring
From: Damian Menscher <damian () google com>
Date: Mon, 19 Jan 2015 15:47:40 -0800
On Sun, Jan 18, 2015 at 4:29 AM, Grant Ridder <shortdudey123 () gmail com> wrote:
It looks like Websense might do decryption ( http://community.websense.com/forums/t/3146.aspx) while Covenant Eyes does some sort of session hijack to redirect to non-ssl (atleast for Google) (https://twitter.com/CovenantEyes/status/451382865914105856).
The ssl opt-out has been deprecated (not sure if it's fully disabled yet): http://googleonlinesecurity.blogspot.com/2014/10/an-update-to-safesearch-options-for.html If you need to disallow adult content, another option is described here: https://support.google.com/websearch/answer/186669 On Sun, Jan 18, 2015 at 10:31 AM, William Waites <wwaites () tardis ed ac uk> wrote:
On 18 Jan 2015 18:15:09 -0000, "John Levine" <johnl () iecc com> said: > I expect your users would fire you when they found you'd blocked > access to Google. Doesn't goog do certificate pinning anyways, at least in their web browser?
User-installed root CAs are allowed to override certificate pins in Chrome. I think a lot of the problem is people have a false expectation of privacy when using their work computers. The legal documents they have you sign on day 1 probably explain that it's their network, their computer, and they will monitor it. If you want privacy, bring your own computer to work (which they probably won't allow on their network...). On Sun, Jan 18, 2015 at 12:49 PM, Geoffrey Keating <geoffk () geoffk org> wrote:
chris <tknchris () gmail com> writes:I have been going through something very interesting recently thatrelatesto this. We have a customer who google is flagging for "abusive" search behavior. Because google now forces all search traffic to be SSL, it has made attempting to track down the supposed "bad traffic" extremely difficult. We have contacted google through several channels and no oneatgoogle who we've worked with is able to provide us any factual examplesofwhat they are seeing and because of the traffic being encrypted all our usual capture and analysis tools have been fairly useless.I presume the problem is that Google has flagged the outgoing address on your NAT, because that's all they can see.
Yup, exactly. Additionally, Google's privacy policies don't allow us to provide the evidence of abuse. Not that the evidence would help anyway, since the searches are encrypted.... Have you considered deploying IPv6 and giving each customer their own
address? Then only that customer will be flagged and it'll be between them and Google.
This is probably the best option. I realize it's not a trivial change so we try to help where we can, but in most cases there's not much information we can provide that would be helpful in tracing the abuse. Damian
Current thread:
- Re: HTTPS redirects to HTTP for monitoring, (continued)
- Re: HTTPS redirects to HTTP for monitoring Ammar Zuberi (Jan 18)
- Re: HTTPS redirects to HTTP for monitoring nanog (Jan 18)
- Re: HTTPS redirects to HTTP for monitoring John Levine (Jan 18)
- Re: HTTPS redirects to HTTP for monitoring Ca By (Jan 18)
- Re: HTTPS redirects to HTTP for monitoring John R. Levine (Jan 18)
- Message not available
- Re: HTTPS redirects to HTTP for monitoring Larry Sheldon (Jan 19)
- Re: HTTPS redirects to HTTP for monitoring John Levine (Jan 19)
- Re: HTTPS redirects to HTTP for monitoring Ammar Zuberi (Jan 18)
- Re: HTTPS redirects to HTTP for monitoring William Waites (Jan 18)
- Re: HTTPS redirects to HTTP for monitoring Kelly Setzer (Jan 18)
- Re: HTTPS redirects to HTTP for monitoring Matt Palmer (Jan 18)
- Re: HTTPS redirects to HTTP for monitoring Damian Menscher (Jan 19)
- Re: HTTPS redirects to HTTP for monitoring Ca By (Jan 18)
- Re: HTTPS redirects to HTTP for monitoring Geoffrey Keating (Jan 18)
- Re: HTTPS redirects to HTTP for monitoring Larry Sheldon (Jan 19)