Ben
As I said in my previous mail, it seems to me that any employer taking
this approach is going to have to do a lot of work to find out whether
it is (and remains) legal. The laws that need to be checked go a lot
wider than just the DPA.

By de-sensitising staff the organisation is also increasing the risk of
those staff failing to spot attacks on them and the organisation. In
particular they are ensuring that it's impossible for staff to
themselves verify the identity of any SSL website which may, to take one
widespread recent example, be attempting to phish the login credentials
for your webmail service.

If my employer were to suggest that encrypted traffic was sufficient of
a problem to require this type of proxy solution, I'd be suggesting to
them that they should instead simply ban and block all encrypted
protocols. Much simpler, both legally and practically. Incidentally I
know of military organisations that have adopted exactly this solution,
though their concern was for information *leaving* the organisation, not
for bad stuff coming in.

Andrew

--
Andrew Cormack, Chief Regulatory Adviser
JANET(UK), Lumen House, Library Avenue, Harwell Science and Innovation
Campus, Didcot, OX11 0SG, UK
Phone: +44 (0) 1235 822302
Fax: +44 (0) 1235 822399

JANET, the UK's education and research network 


> -----Original Message-----
> From: This list is for those interested in Data Protection issues
> [mailto:[log in to unmask]] On Behalf Of Ben Plouviez
> Sent: 24 November 2008 09:11
> To: [log in to unmask]
> Subject: Re: Monitoring of encrypted (SSL) data
> 
> Interestingly, the more I've thought about this, the more relaxed
> about
> it I am.
> 
> I use the web at work to log on to my trade union site - since
> personal
> use for harmless purposes is allowed under my employer's acceptable
> use
> policy. That traffic - normal http: traffic - is intercepted by the
> Blue
> Coat proxy my employer uses and passed through a virus and content
> scanner, to make sure I'm abiding by the acceptable use policy, and
> in
> particular that I'm not downloading executables or videos, both of
> which
> are banned by that policy. If I try to do so, those items will be
> stopped, and the fact logged. Otherwise, the traffic relating to my
> actions on my union's site are passed straight through to me. Note
> that
> sensitive personal information is involved here (trade union
> membership): if I really didn't want to let my employer know that I
> was
> a union member, I would be foolish to log on to that site while at
> work.
> 
> 
> Now think about the interception of SSL (https:) traffic. My
> employer is
> proposing to do pretty much exactly the same thing with that
> traffic.
> This will ensure that they know I'm not downloading executables or
> other
> banned material through this backdoor (and will stop me if I do).
> They
> will not store any other information from the https: stream, any
> more
> than they do from the http: stream, but informaiton about my
> attempts to
> download naughty stuff will similarly be recorded.
> 
> So, there are three issues.
> 
> First: is my personal information safe? Well, theoretically, a
> sysadmin
> could steal my information while it's on the proxy server network -
> s/he
> would, of course, be committing all kinds of offences in doing so.
> That
> high risk/high impact scenario is managed by my employer agreeing
> not to
> intercept https: traffic with banking sites. The risk to them is
> minimal
> (few banks offer malware or even videos as part of their
> services!), so
> the employer can afford to be relaxed about that, and it means that
> the
> most obviously tempting information is unavailable, even
> theoretically,
> to the sysadmins. Without question, some risk to personal data I
> pass
> through the network remains (as it does with http: traffic), and
> good
> logging and security on the servers is essential, as ever.
> 
> Second: is there a good enough reason for doing this? That is a
> business
> judgement about the risks of disruption (caused by malware etc)
> which
> could be caused by my using https: traffic to breach the security
> of the
> network. We could argue about proportionality here, but in the end
> it is
> a business decision and hence up to my employer to decide whether
> or not
> the activity is in their legitimate interests.
> 
> Third: do I need to know? I'm already informed by our acceptable
> use
> policy that my internet use at work is monitored. If I know a
> little
> (but not enough!) about proxy servers and all their ways, I may
> believe
> (and did, until last week) that technically this cannot include
> https:
> traffic. But I would be foolish to try to take advantage of that
> supposed fact by doing something that exposed highly sensitive
> personal
> information that I really didn't want my employer to know while
> using my
> employer's network. And, of course, I would be doubly foolish to
> rely on
> the security of https: to break my employer's acceptable use
> policies -
> or at least I would have no reason to complain if I got caught.
> However,
> since there do seem to be people who believe that internet access
> comes
> free from Heaven and that internet privacy is a divine right
> irrespective of whose internet connection they're (ab)using, it
> would
> probably be sensible for my employer to make it clear exactly what
> they
> are doing.
> 
> Sorry about the length of this! But does anyone have any real issue
> with
> any of it?
> 
> Ben
> 
> -----Original Message-----
> From: This list is for those interested in Data Protection issues
> [mailto:[log in to unmask]] On Behalf Of
> [log in to unmask]
> Sent: 22 November 2008 18:50
> To: [log in to unmask]
> Subject: Re: [data-protection] Monitoring of encrypted (SSL) data
> 
> *******************************************************************
> This email has been received from an external party and has been
> swept
> for the presence of computer viruses.
> *******************************************************************
> 
> There is another aspect which can affect an organisations decision
> on
> the risk balances of an ssl proxy.
> 
> Where a site is connected via ssl to a user, that site has access
> to a
> user's pc outside many of the controls exerted by a firewall.
> 
> Symantec describes this as: -
> "Some Web sites and email servers use SSL (Secure Sockets Layer)
> connections to encrypt connections between your computer and the
> server.
> Privacy Control cannot block private information sent through SSL
> connections. However, since the information is encrypted, only the
> recipient of the email or Web communication will be able to read
> the
> message."
> 
> Becoming proactive would not necessarily solve the problems as
> intelligent consideration of the required growth in organisational
> management and security to effectively control those areas
> indicates.
> 
> Trust can be a funny thing. Imagine a savvy, driven, employee (or a
> corrupt one) setting up their own secure connection at home or
> utilising
> one elsewhere, do you live with that singular possibility, or
> configure
> systems to stop all potential problems?
> 
> 
> Ian
> 
> 
> 
> ********************************************************
> 
> This e-mail (and any files or other attachments transmitted with
> it) is intended solely for the attention of the addressee(s).
> Unauthorised use, disclosure, storage, copying or distribution of
> any part of this e-mail is not permitted.  If you are not the
> intended recipient please destroy the email, remove any copies from
> your system and inform the sender immediately by return.
> 
> 
> 
> Communications with the Scottish Government may be monitored or
> recorded in order to secure the effective operation of the system
> and for other lawful purposes.  The views or opinions contained
> within this e-mail may not necessarily reflect those of the
> Scottish Government.
> 
> ********************************************************
> 
> 
> The original of this email was scanned for viruses by the
> Government Secure Intranet virus scanning service supplied by
> Cable&Wireless in partnership with MessageLabs. (CCTM Certificate
> Number 2007/11/0032.) On leaving the GSi this email was certified
> virus free.
> Communications via the GSi may be automatically logged, monitored
> and/or recorded for legal purposes.
> 
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>      All archives of messages are stored permanently and are
>       available to the world wide web community at large at
>       http://www.jiscmail.ac.uk/lists/data-protection.html
>      If you wish to leave this list please send the command
>        leave data-protection to [log in to unmask]
> All user commands can be found at
> http://www.jiscmail.ac.uk/help/commandref.htm
>  Any queries about sending or receiving messages please send to the
> list owner
>               [log in to unmask]
>   Full help Desk - please email [log in to unmask] describing
> your needs
>         To receive these emails in HTML format send the command:
>          SET data-protection HTML to [log in to unmask]
>    (all commands go to [log in to unmask] not the list please)
>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     All archives of messages are stored permanently and are
      available to the world wide web community at large at
      http://www.jiscmail.ac.uk/lists/data-protection.html
     If you wish to leave this list please send the command
       leave data-protection to [log in to unmask]
All user commands can be found at http://www.jiscmail.ac.uk/help/commandref.htm
 Any queries about sending or receiving messages please send to the list owner
              [log in to unmask]
  Full help Desk - please email [log in to unmask] describing your needs
        To receive these emails in HTML format send the command:
         SET data-protection HTML to [log in to unmask]
   (all commands go to [log in to unmask] not the list please)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^