7

The Situation

I am in an office with a connection that is routed through a BigIP firewall, with SSL interception; our computers have a root certificate to permit the intercept certs. If I browse to a site such as https://www.google.com/ and view the security certificate, I see the certificate issued by the firewall, but browsers merrily accept it because it maps to a root cert on the computer.

I have a VPN connection that is tunneled around the firewall; the certificate used in the VPN negotiation is the expected VPN server certificate, indicating that the firewall is not intercepting this connection. When connected, all my traffic is routed over the VPN, and HTTPS traffic displays the proper site certificates instead of the firewall certificate, indicating that my HTTPS traffic is no longer being intercepted.

The Confusion

Every so often, the VPN server momentarily drops connection (OpenVPN shows that it's renegotiating the connection, then reconnects within 3-5 seconds). What happens to any AJAX/other background HTTPS requests that run while this is happening? The connection never seems to miss a beat (updated data continues to refresh on the page), suggesting that traffic continues flowing even while the VPN connection is down.

Does the browser renegotiate the HTTPS connection momentarily (and transparently) using the firewall certificate while the VPN connection is down? Or does the firewall somehow see that the data is part of an existing connection and pass the data without MITMing it? Or do the AJAX calls actually get rejected because of the certificate change-up, and the page is just continuing to refresh stuff it picked up before the drop so it only feels continuous to me?

The Specifics

  • Platform: Windows 7
  • Tunnel: OpenVPN server, with OpenVPN GUI client
  • Browser: Google Chrome (and sometimes Mozilla Firefox)
  • Firewall: f5 BigIP, possibly AFM

This is not a question about whether bypassing a firewall with a VPN is (moral, ethical, legal, etc); this is a question about what happens to data when the VPN drops momentarily, and whether it may be subject to interception. I have authorization to do this specifically because of legal implications.

Community
  • 1
Doktor J
  • 324
  • 2
  • 8
  • Are you able to put an intercepting proxy (Burp, Charles etc) in the middle to monitor this traffic in real time? – TrickyDupes Sep 14 '17 at 14:51

2 Answers2

3

The "tcp" in your network stack will happily compensate for an outage less than the the tcp timeout, asking the server to resend any packets it has missed. The existing socket connection will not be switched across a different route (this is often done on routers but not on endpoint devices). Since the tcp network stack is very good at this, there is no capability within the browser to handle such events.

I don't see how content could be delivered without any network connection. Note that rendering and javascript execution occur asynchronously from the content retrieval (both from servers and local cache) hence the screen may change without data packets being exchanged.

symcbean
  • 18,278
  • 39
  • 73
  • 1
    There *is* a connection though, when the VPN drops out: the connection that (potentially) gets routed through -- and MITM'd by -- the firewall. Unless the endpoint routing is such that it makes switching impossible, my concern is that it'll get switched across the firewalled connection and the browser will merrily accept the MITM cert without a peep, then go back to the VPN connection and legit cert when the VPN comes back up. – Doktor J Sep 14 '17 at 23:17
1

Your VPN application general installs itself as a network driver. This means that it tells your system 'Hey! Send all your traffic through me!'

Now when your VPN drops out, it could be caused by several things:

  • Errors between your router and system

  • Errors in the VPN driver/application or some external influence forcing the system to stop using the network adapter

  • Your ISP just had a minor outage (unlikely)

  • Combinations of the above.

In all these cases, the minute the connection drops out, the *network adapter or your VPN adapter will die. This is solely based on your system configuration and it's speed/ability to switch. This is the equivalent of turning on a tap and reaching under the sink to turn off the valve. There's nowhere for those packets to go. BUT - IF your system is able to or is configured to use another adapter as a fall back, then depending on just how fast it is able to switch, it is possible for your system to continue sending these packets onto their destination - which means that your firewall will be able to view the contents again.

Other possible mitigation strategies might include blocking all ports except your VPN ports (Block everything except UDP 1194) - This will ensure that all data must be routed through the VPN port.

However, many sites will immediately log you out if they detect packets containing the same cookie coming from multiple IPs seconds apart. But again, there's a chance that data might be transferred and read by your employer (or the person managing the firewall).

Additionally, I should mention that many VPN programs come with a kill switch that monitor if your VPN connection fails, and instantly stop transmitting packets. OpenVPN doesn't yet.

thel3l
  • 3,384
  • 11
  • 24
  • I would imagine that there would be a timeout if there is a dropped connection, and the "tap" would only go down after the timeout. I would hope that the network adapter would be robust enough to buffer packets during a renegotiation. Since this is a known state by the implementation. – RoraΖ Sep 14 '17 at 15:16
  • @RoraΖ Absolutely, fair point. But doesn't that still support my overall 'It's likely, create a kill switch'? :P – thel3l Sep 14 '17 at 15:19
  • Its not the network adapter which does this, its the CWND in the TCP stack which buffers. – symcbean Sep 14 '17 at 19:10
  • @thel3l I think that while your description of what happens when a connection is officially terminated is well done, but I think it's a bit misleading to say "In all cases the **minute** the connection drops out your VPN adapter will die". Using another adapter as a fallback is not the only mitigation to the problem. I feel like your last sentence in that should be stated a bit earlier :) – RoraΖ Sep 15 '17 at 17:21
  • @RoraZ, agreed, fixed it. Danke! – thel3l Sep 15 '17 at 17:27