0

This question already has an answer here:

I have reason to believe that my employer may be performing HTTPS man-in-the-middle attacks on company-issued work laptops, as Java's SSL Certificate lists my employer as the Certificate Authority.

When launched, the Java Platform (jp2launcher.exe) displays a warning that the connection to https://javadl-esd-secure.oracle.com:443 is untrusted, and that "The certificate is not valid and cannot be used to verify the identity of this website."

Clicking More Information opens a window stating that "The digital signature for this application was generated with a certificate from a trusted certificate authority, but we are unable to ensure that it was not revoked by that authority." A link to the Java help page for self-signed certificates is also included.

I cannot share the full certificate details, as doing so would reveal the identity of my employer. However, I can confirm that Java lists my employer as the Certificate Authority.

Is my employer running man-in-the-middle HTTPS attacks? If so, should I be concerned about potential security exploits?

I've read that HTTPS scanning can lead to weakened browser security, such as when Kaspersky exposed users to MITM attacks earlier this year. If company-run HTTPS scanning is common practice, couldn't it fall victim to the same previously mentioned security issues?

Censored SSL Certificate

marked as duplicate by schroeder Jul 14 '17 at 20:49

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 4
    It's not an attack when the company owns the computer, and has installed their own certificate in the certificate store. This is common for most companies in order to be an HTTPS proxy for their hardware. I'm surprised that it says the certificate isn't valid, but I guess that's part of the uncertainty of the revocation. – RoraΖ Jul 14 '17 at 14:05
  • 1
    @StevenVascellaro your question has a few ideas jumbled. You classify the behaviour as an 'attack', but this is standard procedure in many companies. Do you want to know if this is an attack as opposed to legitimate behaviour? Second, you identified that the employer is the trusted certificate then ask how to identify how you employer is a MitM, but you just did. The proposed duplicate, is in fact, the answer you are looking for. – schroeder Jul 14 '17 at 14:26
  • How to detect man in the middle attacks is actually explained in many questions here, including one I've pointed out on your previous question about this topic. That's why I've marked it as duplicate. When reading the answers to these questions you will realize that the information you provide are not sufficient. But when you understand these answers you should also be able to figure out yourself if MITM is done or not. – Steffen Ullrich Jul 14 '17 at 14:30
  • 1
    @RoraΖ, the certificate is not signed by an authority Oracle trusts, which is probably the only reason the launcher said "not valid". And yes, this is a common problem at organizations that use https inspecting proxies. – John Deters Jul 14 '17 at 23:46
2

As promised, here is a copy&paste of my answer to your previous question.

Ok, you've found your company's CA cert in your java trust store. That tells us that they have the ability to perform the MitM attack that you are describing, but it does not prove that they are actually doing it. That cert may be there for a completely legitimate reason, like for example so your VPN client can authenticate the VPN server, or so you don't get certificate errors when connecting to internal network resources. As @schroeder says, this is completely normal behaviour for companies that issue laptops or have BYOD policies. In this case, it seems like they installed the certificate so they they can code-sign their java applets. It also sounds like they did a bad job of setting up their CA since they have not provided revocation information for the certs. There is nothing in your question to indicate that they are doing any HTTPS interception.

To be sure that they are inspecting HTTPS traffic, you need to actually catch them in the act. When you make a TLS connection that you suspect of being MitM'd, look at the server cert you are presented; if it chains to your company's CA then that connection is being MitM'd and you'll have proof, but if it chains to a publicly trusted CA then it's secure.

You'll need to do some digging about the java application you're using to figure out how to see the details of each TLS connection (you may be able to do this through JVM settings, but I'm not sure). Browsers, for example, are quite good about showing you the details of the TLS connection.

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