
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN">

<html><body>

<p>Snap used to use this method to allow people access to secure bank sites to pay their bill when they were overdue. </p>

<p>On Fri, 26 Oct 2012 19:43:48 -0700, Scott Howard wrote:</p>

<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px; width:100%"><!-- html ignored --><!-- head ignored --><!-- meta ignored -->

<p>On Fri, Oct 26, 2012 at 4:21 PM, Paul Gear <span><<a href="mailto:ausnog@libertysys.com.au">ausnog@libertysys.com.au</a>></span> wrote:</p>

<div class="gmail_quote">

<blockquote class="gmail_quote" style="margin: 0  0  0  .8ex; border-left: 1px  #ccc  solid; padding-left: 1ex;">

<div>So what do you do for the scenario where you're providing service for BYOD or public networks (as the OP seemed to be) and have no authority to touch the end user's device?  When we tried this, we came to the conclusion that we would have to allow unfettered outbound HTTPS if we weren't to have massive user experience rage, and this basically eliminates the benefit of any filtering.</div>

</blockquote>

<div><br />It depends on what you're trying to achieve.  If it's simply to block/allow access to a site you can do this based on the certificate exchange alone.  The certificate sent during the initial SSL handshake includes the hostname of the website (or at least some variation on hostname, wildcard hostname, alternate names, etc) and is sent in clear-text, so the connection can be blocked based on that hostname.  <br /><br />It's a very course solution as at best you can get to the host granularity (not URL), you can't inspect the content at all (eg, anti-virus), and there's numerous ways to get around this (think self-signed certs for starters, but there's countless others) - but it'll stop at least the average user.<br /><br />  Scott</div>

</div>

</blockquote>

<p> </p>

<div> </div>

</body></html>