I would like to know whether a firewall can scan an HTTPS packet, to verify its source, destination, and data.

Or how to stop a user from sending the file over HTTPS if it contains some unwanted data.


There are two aspects to prevent data loss of the type you are concerned about.

  • Deep Packet Inspection

    For HTTPS which is, of course, encrypted between the source and destination, you need a security service that has, as Mark said, a certificate trusted by your users browsers. It acts as a Man-in-The-Middle and so is able to continue to inspect all of the packets going through, even those that would normally be encrypted.

    Any decent system will do this dynamically based on a risk score and will white-list destinations such as personal finance sites so that you can continue to offer users a degree of privacy while ensuring organisational and unknown traffic is monitored.

  • Data Loss Prevention

    DLP uses rules to identify information that you might consider sensitive. Nationl Insurance numbers, credit card numbers, drivers license ids, etc.

    Using a risk scoring system, the DLP will watch for sensitive information leaving (and entering if required) the organisational boundaries and provide alerts when rules are exceeded.

    Clearly DLP also requires the ability to intercept encrypted communications but you will probably implement DLP in more places. Certainly in the security boundary but also on organisational computers, especially laptops and desktops. Maybe mobiles too.

    DLP is particularly critical in regulated industries such as health and finance.

One thing that I personally believe critical if you plan to implement things like this is to inform all users that their traffic is being monitored. You should make sure that information is baked into any Acceptable Use Policies and Information Governance policies. You should also include it in your Terms and Conditions of Use.

If you don't do that, you open yourself to accusations of intercepting private communications. Note that organisational communications generally get special exemptions from some privacy rules since there is an expectation that corporate communications contain corporate information.

UPDATE: Lest you think this is the realm of the paranoid as @Somone Somewhere seems to, let me assure you that it isn't.

While data can be exfiltrated in a number of ways that would bypass centralised security infrastructure, it would still catch the majority of risks:

  1. Users deliberately sending sensitive data somewhere they shouldn't. This might be for nefarious reasons though more commonly it is to send it to a less protected, non-corporate system (e.g. a home PC) to do something they are not allowed to do at work. While this may seem convenient to them, they may well be breaking the law and they are in danger of leaking the sensitive information (think about patient information, contracts, etc)
  2. Malware. There are plenty of types of malware that attempt to exfiltrate sensitive information. Some targetted at specific industries (health records are particularly valuable) and others at general information such as banking and other finance details. Malware authors are not stupid, most malware comms is encrypted. Patterns of traffic other than genuine HTTPS can often be detected and if HTTPS traffic is identified and cannot be decrypted, that too indicates malware.

Just because a security infrastructure is not 100% effective doesn't mean that it is ineffective.

At the end of the day, your organisation needs to weigh up the risks and costs and decide what level of security is needed. Risks will take into account the value of the data you hold, any legal constraints and how much of a target you are.

When considering the legal constraints, don't forget to take into account that corporate executives may be held personally responsible for sensitive data leaks.


Any HTTPS packet is encrypted, and normally no one is able to see the data inside (anything in the packet payload) except for the two communicating HTTPS endpoints (usually the user PC and the web site PC), who both have the crypto key to decrypt it. The IP addresses (both sender and receiver) of the HTTPS packets are both unencrypted so that the packets can be routed by points between the sender and receiver.

Businesses and other organizations such as schools often install certificates in all the PCs under their control so that a proxy/gateway server to the internet can open and inspect any HTTPS packets for inappropriate web site browsing or malware/virus containing downloads. In this case, there are two HTTPS connections; the one between the user PC and the gateway, and another between the gateway and the website the user is visiting. The data is encrypted at the user PC, unencrypted and inspected at the proxy/gateway server and then re-encrypted until it reaches the web site where it is unencrypted again. Packets returning are also opened and inspected by the proxy/gateway server.

As for stopping HTTPS, this is possible to do at a firewall but this would kill most internet browsing since most web sites either use HTTPS or are moving that way for security. Without the ability of a proxy server to open and inspect packets, stopping HTTPS packets is all or nothing; you can stop all of them or none of them, but can't filter packets by what is inside them.


Source, yes.

Destination, yes (at least to the IP. If multiple sites are hosted from one IP, it may not be possible to determine which).

Data, no, other than the amount of it.

You could use MITM inspection, but this requires installing certificates on all client machines and I strongly recommend against it due to a variety of privacy and security reasons.

As to how to stop them, prevent them getting the data in the first place. If they have the data, they could, amongst other options:

  • Copy it to a USB stick, local storage, or CD, or print it, and walk out of the building with it.

  • Encrypt or obfuscate it, then send it.

  • Use a different network, e.g. cellular.

  • Remember it, for smaller quantities.

  • 1
    Your assertion that this is not recommended is, I'm afraid, incorrect. Many organisations have a requirement to do this in order to be able to protect their data and users. Generally, the better security systems are able to understand genuinely personal sites such as personal finance and won't intercept those. Doing this lets an organisation be more flexible with its Internet provision rather than having to lock everything down indiscriminately. Sep 11 '16 at 9:11
  • I've slightly edited the answer to make it clear that's my opinion. Nonetheless, it's an easily bypassed attempt to filter it, plus most of the implementations have horrific security issues (server accepts any SSL cert without verification, program the browser to accept a publicly known private key, for example). Also, banking is not the only thing that is private, and a simple whitelist is not going to pick up everything. Do you want to be the one explaining why your webfilter stored (and leaked) 3000 employee personal credit card numbers? Sep 11 '16 at 9:25
  • Thanks. I certainly agree with your point about circumvention. I've never worked anywhere that you couldn't circumvent the security if you wanted to (though there are certainly places where you couldn't). However, it will still prevent a very large number of data exfiltrations and, more importantly, will help spot malware C3 comms. It is critical for regulated industries at least. Sep 11 '16 at 9:32
  • The whitelists are dynamic in a decent system and a risk score is calculated on the fly based on a number of factors. No it wont pick up everything but if you are doing personal things on a corporate network, your expectation of privacy is very different to doing things at home. Communications is the key as in my answer. As for leaks from the system, it most certainly will NOT be storing information, only monitoring for it (DLP) and for unexpected traffic, its position in the centre of your network should provide sufficient protection (no more room to explain, raise a Q if you want more). Sep 11 '16 at 9:35
  • If you're that paranoid, I think completely separating the internet would be a better solution than trying to filter. Inadvertent exfiltrations would almost exclusively be either email or some physical medium - paper, usb stick etc. I doubt 'oops I uploaded customer data into a web form' comes up often. Most large enterprises would use a centralised email server anyway; no need to force yourself between the client and the net. Sep 11 '16 at 9:38

A firewall can scan an HTTPS packet but can not decryption it because decryption required a SSL Certificate (A key to decrypt data packet)

You can get source and destination information but it is not possible to scan Data packet which is sent over HTTPS Protocol.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.