4 ms·
It's great that Google wants to move more sites to https, and I'm in support of this, but it also creates challenges for security vendors such as myself. Curre
by LogicX 10y ago
It's great that Google wants to move more sites to https, and I'm in support of this, but it also creates challenges for security vendors such as myself.
Currently DNSFilter and others Man in the Middle traffic destined for sites our customers have decided to block. This works great for http,
but not https, as certificate warnings are presented.
The standard work around is arguably less secure: adding a third-party CA to all end-points. This can still present problems with HSTS and certificate pinning.
I'd like to work with Google to create a standard where vendors can either be on a whitelist or have new recognized SSL cert fields, not to MITM traffic, but just to present users with a friendlier message explaining whats happening, and providing a separate https:// https:// url to visit for information from the vendor about the block.
Implementing such a standard in browsers would further increase user security, and provide a viable method for filtering on guest networks where there is no end-point access.
- scrollaway 10y agoRemoving insecure HTTP altogether is the road Google is taking. That should make this a non-issue.
- toast0 10y agoHow does removing HTTP solve the issue presented: When actively interrupting an HTTPS connection as a network element, there is no way to provide information to the user about the reason for the interruption or steps the user could take to prevent the interruption. This can be done with HTTP, where a filtering proxy could show a page 'our software thinks this page violates company policies, but click here to override or contact IT to fix', or see also captive portals. Maybe the right answer is simply there's no reasonable way to handle this use case in a secure manner, but taking away an established use is a real issue.