At work my company uses internet monitoring software (Websense). I know if I visit a https ssl-encrypted site (such as https://secure.example.com) they can't see what I'm doing on the site since all the traffic is encrypted. But do they see, that I visited https://secure.example.com?
An encrypted connection is established first before any HTTP requests are performed (e.g.
HEAD, etc.), but the hostname and port are visible.
There are many other ways to detect which sites you’re visiting as well, for example:
- your DNS queries (i.e. they’ll see the IP request for secure.example.com)
- via network monitoring (e.g. netflow, IP to IP sessions, sniffing, etc.)
- if the device you are working on is owned by the company and they have administrator access/privileges to view anything on the device (e.g. view your browser caches)
A popular way to evade a Websense proxy is to first establish a connection via HTTPS to an outside proxy (e.g. https://proxy.org/) and make your request from there.
It is possible, but it requires some setup. Here is how it is done, and how you can tell.
On a corporate computer, where software updates are pushed from a central location, it is possible to send to your computer a "trusted" certificate that will be stored next to the trusted certificate of say, Verising or Entrust.
Your company's proxy will hold the private key of that certificate.
When you visite a HTTPS web site, like https://mybank.com/, the proxy will put itself in the middle. It will establish a HTTPS connection with your browser generating on the fly a certificate for mybank.com. It will replay (and possibly monitor or log) all you traffic on a new connexion, from the proxy to mybank.com.
You can tell if this is the case by looking at the padlock icon. If you see that the certificate for mybank.com was issued by acmesprockets.com (the name of your company), then you know they can see your "encrypted" traffic. But since you company can force your computer to trust any certificate, they could create a certificate using a well known name, like "Entrust.net Secure Server Certification Authority" (even if that would probably be illegal under some trademark law).
So how can you tell? After connecting to the website, look at the certificate. Details vary for each browser, but clicking on the padlock icon next to https is usually the place to start. From that certificate, find the certificate thumbprint and look it up online. Better yet, do the same thing with the certificate authority. If you don't find the certificate thumbpring online (but you can when you are at home or on your phone), chances are your HTTPS traffic is decrypted along the way.
Simple Proxy Servers
Even a simple proxy will see and log the names of the servers. For example visiting https://example.com/some/address.html will create a request like this from the browser to the proxy server:
CONNECT example.org:443 HTTP/1.1 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b13pre) ... Proxy-Connection: keep-alive Host: example.org
The rest of the connection is encrypted and a simple proxy just forwards it.
Complex Proxy Servers
There are, however, more complex proxy servers, that are able to see the complete traffic in plain text. These kinds of proxy servers, however, require that you have a root certificate installed for which they can create server certificates on the fly.
Looking at the certificate chain in the browser usually reveals this kind of man in the middle attack. At least in the common case of it being done by your own company and not state agencies:
With HTTPS, the SSL/TLS tunnel is established first, and HTTP traffic happens only within that tunnel. Some information still leaks:
If the client uses a proxy, the connection to the proxy looks like:
CONNECT www.example.com:443with the target server name. Alternatively, the client could send the target server IP address, but this is only marginally less revealing; and, to know the server IP address, the client must do some name resolution, using the DNS servers provided by the company itself.
Recent enough clients will send the target server name as part of the initial SSL handshake (that's the Server Name Indication extension).
The server responds by sending its certificate back, which includes, in plain view and by definition, the server name.
From these we can conclude that the target server name is definitely not a secret. You may assume that your company learns it.
The rest of the communication is encrypted so it is nominally inaccessible from outsiders. However, the length of the data packets which are sent and received by the client can still be inferred by any eavesdropper (with single byte accuracy if a RC4 cipher suite is used), and this can also reveal a lot of information, depending on context.
If your company is serious about security then it may have installed a more advanced proxy like Blue Coat's ProxySG. Such systems perform a Man-in-the-Middle attack by dynamically generating a fake certificate for the target server. This gives them access to the complete data, as if there was no SSL.
Note that, however, such interception is possible only if the company could add to the trust store of your desktop system the root CA certificate that the proxy uses to issue the fake certificates. This is a rather intrusive action. Therefore, if they could do that, why would they stop there ? They may have inserted, just as easily, a handful of spying software which will plug in your Web browser, your keyboard and your display; and everything you do on the machine is known to them.
Alternatively, if you can make sure that your machine is free from any interference from your company (e.g. it is your own device and you installed no company-provided software on it), then MitM-proxy cannot decrypt your SSL connections.
A very simple way to hide your traffic from your company is not to use their facilities at all. Bring your own laptop with a 3G key (or tethered to your smartphone). By paying for your own Internet, you can evade network-based detection and spend your days roaming the Web instead of doing the work you are paid to do (but, of course, detection of slackers has never been restricted to only using computerized gizmos).
If websense is configured to log it, then yes, they will be able to see where you went, all the URLs you visit.
Content is less likely to be viewed - it depends on how websense/proxy is set up - but it can be done. It depends whether the SSL session is from your browser to the server or if it is just to the proxy (effectively running a man in the middle attack)
They can see all of your SSL traffic unencrypted if they use a BlueCoat proxy or similar. Many large Enterprises do this.
Following on Guillaume's answer, another way to check for foul play is to use the "Perspectives" Firefox add-on. When visiting an https site it checks (through Internet "notaries") that the public key you receive (via the web server certificate) does indeed belong to the site you're visiting.
Yes, your company can monitor your SSL traffic.
Other responses say that SSL is secure, indeed it is.
But, your corporate proxy can intercept and inspect your encrypted traffic as denoted by the image below:
This image is when I visit Google in my work computer.
Here, they use the Forefront Threat Management Gateway 2010 which can intercept the connection between me and a secure site.
The SSL (Secure Socket Layer) and TLS (Transport Layer Security) security is based on PKI (Public Key Infrastruture).
The PKI consists on a series of trusted certificates called root certificates.
Here in my company, one of the root certificates is the certificate which Forefront generates the certificates for each website I visit.
Because my computer trusts the certificate which the proxy used, no warning was generated and the connection is done securely but can be inspected by the proxy server.
Not just from certificate but also from handshake messages servername information can be get. As I tested %80 of the traffic contains server_name extension in client hello message(first message send by client to server in https protocol) . But this extension is optional and sometimes it does not exist .In this case certificate can be checked. In certificate there exist server name again .