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.
Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this communityI 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.
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:
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.
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.