On Fri, Oct 26, 2012 at 4:21 PM, Paul Gear <span dir="ltr"><<a href="mailto:ausnog@libertysys.com.au" target="_blank">ausnog@libertysys.com.au</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

  
    
  
  <div bgcolor="#FFFFFF" text="#000000">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.<br></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<br></div></div>