This blog was originally published to the 128 Technology website – in 2020, Juniper Networks acquired 128 Technology. Learn more about the acquisition here.
I learned something over the past few weeks that really surprised me, and I wanted to share it with the 128T community. I discovered that HTTPs proxies are transparent – and it’s even more prevalent than you might think.
Transparent HTTPs proxies (also called SslBump) intercept your encrypted Internet communications without your knowledge. Even if you do not configure an outbound proxy, and you do not submit to mobile device management, and even without you ever agreeing in any way, a firewall can mimic the original TLS/SSL server certificate when bumping traffic [this article explains in much more detail].
And your browser will not warn you or indicate that anything is amiss. Palo Alto performs the exact same capability, as do most next-generation firewalls. The firewall actually terminates the inbound TCP connection and issues its own client certificate to the secure website. Upon receiving the server certificate, it actually “on the fly” creates a new server certificate by scraping out the text information from the actual server certificate. This new certificate, created on the fly, passes all of the tests for validity on your endpoint, because the firewall has been endowed as a subordinate certificate authority, or sub-CA, from a trusted CA. But none of the information in the created certificate is truly valid. [watch this video for specifics].
The following table provides a summary of how typically the fields from the original certificate are used by the transparent proxy to create the new certificate:
| X.509 Certificate Property | After Successful TLS/SSL Bumping |
|---|---|
| Common Name (CN) | By default, True CN is used. Is overwritten sometimes |
| Alias | True alias |
| Subject Name | True subject name by default. Is overwritten sometimes |
| Subject Alternative Name | True names, if any, by default |
| Signer and Signature | Self-signed CA or the sub-CA, as configured on the transparent proxy. Signature is generated using the private key of the self-signed CA or the sub-CA. |
| Issuer Name | The subject name of the signer certificate |
| Serial Number | 20-byte SHA1 hash, generated on the transparent proxy |
| Validity Dates | By default, true dates, copied from the original certificate |
| Version | By default, true version, copied from the original certificate |
I decided to figure out how I could easily become a sub-CA and get a self-signed certificate, and learned the process is quite easy [check out this article]. To do this correctly, I might have to actually spend money on getting a real CA certificate, but otherwise there appears to be very little oversight of the process.
I am disturbed at how easy it is to insert a “man-in-the-middle” of any highly valuable encrypted communication, but the truly shocking aspect is how easy it is to create a false certificate to trick or fool a browser into providing an “all is good” signal to the clients browser. The value of encryption when a “man-in-the-middle” can secretly read or observe information passing between them surprised me. I believed that without an outbound proxy configuration I was safe, and my browser would warn me of threats.
On March 21 of this year, TLS1.3 was finalized, and is now the standard for session layer encryption. TLS1.3 encrypts the server certificate, making it impossible to passively decrypt sessions for analytics. This was as far as they went to prevent a “man-in-the-middle”. It is unlikely that any new standards will emerge that can provide a guarantee that there are NO men hanging out somewhere in the middle.
Obviously, your client/server applications can inspect the certificates presented in detail to ensure no SslBump is on the wire, and this is good for sophisticated operations. But for generalized HTTPs services, this is not really practical.
Now here is the obvious plug for the 128T Networking Platform, but I believe you’ll find it helpful and perhaps comforting.
At 128 Technology, we created the Secure Vector Routing (SVR) protocol to drive the 128T Networking Platform, and it cannot be intercepted passively – seriously. You see, the routers that are running SVR and bookend a 128T network will only accept security keys bilaterally, and as such no passive interception is possible. When TLS traverses a 128T network, it also cannot be intercepted for two other reasons:
- The packet port numbers are anonymized, and the per packet HMAC calculation will detect any packet modifications and protect against replay attacks.
- FIPS 140-2 certified per packet encryption will prevent eavesdropping.
- The firewall detector will sense there is a firewall present, and switch the packets from TCP to UDP.
So, in my opinion, if you are sending traffic that needs super security, using the 128T Networking Platform is really the way to go.
