Is encryption in HTTPS done by the browser or by the system?

Question

This may be a common sense question, but I am not able to find any documentation on this after searching on google for a long time

When browser makes a HTTPs request, does it encrypt the data then and there, and any proxy (even on the same system) will receive the data in an encrypted form? Can that data be tampered successfully via proxy (on the same system, not on network)?

If browser does the encryption/decryption, then please let me know if there is any documentation which says so. Or whether the encryption/decryption is taken care by underlying SSL protocol only at the transport level (when the request is in network).

Answer 1

The ‘S’ in HTTPS stands for ‘secure’ (Hypertext Transfer Protocol Secure) It is a communication protocol for secure communication that makes use of Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL).

TLS/SSL is initialized at layer 5 (the session layer) then works at layer 6 (the presentation layer). Most applications, like web browsers, e-mail clients or instant messaging incorporate functionality of the OSI layers 5, 6 and 7.

When referring to HTTPS it will be an implementation of SSL/TLS in the context of the HTTP protocol. SSL/TLS will then be implemented in the browsers (and web server) to provide confidentiality and integrity for HTTPS traffic (actual encryption of the data).

Chromium and Firefox use an API called NSS to implement SSL/TLS within their respective browser.

Microsoft Windows for example has a security package called SChannel (Secure Channel) which implements SSL/TLS in order to provide authentication between clients and servers. Schannel is for example being used by Microsoft Windows clients/servers within an Active Directory environment.

As for the proxy and tampering of the data it depends of the protocol you're working with. A good example to familiarize yourself in an HTTP(S) context is to have a look at Burp Proxy.

Answer 2

There's a lot of good answers here about how HTTPS is handled by the browser, but I'm not sure your real question has been addressed.

Can that data be tampered successfully via proxy (on the same system, not on network)?

Here the answer is yes. This could happen one of two ways:

• The browser itself is compromised by a malicious plugin, extension, or update.
• The system is compromised with malware that has altered the Trusted Root Certificates used by the browser (which may or may not be the same one used by the OS).

Answer 3

The answer is ... possibly.

If you specify https://, then the browser is taking responsibility for encryption. Some browsers use OS-provided APIs (looking at IE here) while others (e.g. Firefox) tote along their own crypto and completely ignore the crypto provided by the OS.

The tamper-resistance is guaranteed by the PKI. So if your system's trusted certificate store gets corrupted, then all bets are off. For example, some corporations will install their own internal signing CA certificate which allows them to man-in-the-middle proxy any secured browser sessions without raising any alarms by the browser. Here again, on Windows the CAs certs are managed by the OS if you use IE or Chrome, while Firefox has its own unique and separate trusted CA list.

But If your system is compromised, then you're toast. No security can be guarenteed, not even SSL. This is because malicious agents can embed themselves anywhere in chain; perhaps at the network level, but perhaps also in the browser, or in the display driver, or listening for keystrokes... nothing is safe. There's a popular class of malware today which inserts itself into the browser to read and modify encrypted data before it gets encrypted and after it gets decrypted. One goal, for example, is to slightly modify your experience at an online banking site to drain bank accounts and transfer all your money to the attacker.

Answer 4

The browser encrypts the data, providing that it trusts the SSL certificate/public key it has been given by the server it's accessing, which is then passed to the server and decrypted in order to start an encrypted "session", between the two entities.

Excellent, easy to understand explanation here.

1. Browser connects to a web server (website) secured with SSL (https). Browser requests that the server identify itself.
2. Server sends a copy of its SSL Certificate, including the server’s public key.
3. Browser checks the certificate root against a list of trusted CAs and that the certificate is unexpired, unrevoked, and that its common name is valid for the website that it is connecting to. If the browser trusts the certificate, it creates, encrypts, and sends back a symmetric session key using the server’s public key.
4. Server decrypts the symmetric session key using its private key and sends back an acknowledgement encrypted with the session key to start the encrypted session.
5. Server and Browser now encrypt all transmitted data with the session key.

Some valuable information about CAs (Certificate Authorities): https://en.wikipedia.org/wiki/Certificate_authority

Answer 5

The browser handles the decryption normally. There are some exceptions to this though. Proxies can strip SSL (in which case the lock icon won't show normally) or they can be slightly smarter and resign the SSL with a certificate that is trusted by the client such that the lock still shows up, but the information about the cert is changed. Really advanced setups can actually monitor the SSL connection if they have access to the server's private key without changing anything though they are used server side, not client side (because of the way the key is derived for an SSL session).

Answer 6

SSL encryption is setup by the browser (or any application which uses SSL), even when a local proxy resides on the system. An example for instance is that when you are doing a pentest you need to setup a local proxy to have your own certificate to be able to decrypt the traffic between the browser and the endpoint.

Answer 7

The SSL/TLS specifications dictate the over-the-wire protocol, but they say nothing about how a client is implemented. Typically, the operating system kernel provides a basic unencrypted TCP socket. To implement the SSL layer, the browser calls functions in a cryptographic library (such as OpenSSL, SSLeay, GNUtls or NSS). Thus, the SSL support would typically happen in userspace, in the same process as the rest of the browser.

As for whether you consider the SSL support to be provided by the "system" — it depends. The browser may link to the cryptographic library statically or dynamically. A dynamic library (or DLL) could be distributed with the operating system, or the browser vendor may ship its own copy of the library.

On the server side, the situation is often similar, where a web server module provides SSL support (in userspace, in the same process as the rest of the web server). However, alternative setups are common as well. Cryptographic support may be hardware accelerated. A reverse proxy, such as a load balancer, may sit in front of the real web server and translate between HTTP and HTTPS, in which case the data may travel unencrypted within the content provider's network.

To address the concern of data interception and tampering: Anyone who has access to the server's private key can easily decrypt the transmission. As a corollary, any server that presents a certificate that is signed by a certificate authority trusted by your browser can spoof the website, as long as the hostname on the certificate matches the hostname in the URL. (For example, Opera operates a proxy for its Opera Mini product. The Opera Mini browser funnels all traffic through Opera's proxy and fully trusts the certificate presented by the proxy. Therefore, although traffic between the browser and the proxy may be encrypted, and traffic between the proxy and the content web server may be encrypted, Opera has the technical ability to read all of the data going through its proxy.) Finally, anyone who has the ability to tamper with the browser (by some extension or plugin mechanism) or the dynamic linker (using something like LD_PRELOAD) or the browser's trusted certificate list could also intercept the data, though at that point the client's integrity has been so compromised that there is no hope for any meaningful security.

Answer 8

A proxy installed on the client machine can indeed intercept an decrypt HTTPS traffic.

However, in order to do this, it must place its own certificate in the trusted root certificate store. In doing so, the user will be prompted with several security challenges, which cannot be easily bypassed. So it's unlikely that this technique would be used by malware unless the user was foolish enough to allow it to happen.

A great example of software using this technique for non-nefarious purposes is Fiddler - an HTTP/HTTPS debugging tool for web developers.

• You can read about how to enable HTTPS decryption in Fiddler here.
• You can see screenshots of the dialogs the user must accept here.

Answer 9

What do you mean by "system?" The encryption should occur in some library. That can be regarded as part of the system in some ways, and in other ways as part of the browser. (Even the browser itself is part of the system, in the sense that it's installed for all users who share the executable.)

The security granularity is that the entire browser and its components are in the same security context (e.g. operating system process with its own address space). The crypto takes place in that process.

To intercept the plaintext data, the software would have to find a way to violate the security context of the browser. This is usually possible in operating systems that have only coarse-grained security policies, for code which has somehow acquired superuser privileges.

E.g. in in Unix-like operating systems we can use the ptrace system call to attach to a process, and do various things like suspend and resume its execution, monitor is system calls, or examine/modify its memory.

Data coming into the browser, such as keystrokes you enter into forms, originates in some other security context, namely the one which contains the keyboard driver in the operating system kernel. That can also be attacked by privileged program that are able to gain access to data passing through drivers.

However, an HTTP/HTTPS proxy (as opposed to a malicious superuser program that peeks into processes) running on the same machine would not have access to plaintext traffic. What passes through a proxy is the encrypted HTTPS protocol.