{
	"id": "6563d65a-8b82-4abb-8ee3-772ca3f0ed55",
	"created_at": "2026-04-06T01:32:14.780646Z",
	"updated_at": "2026-04-10T03:19:56.826588Z",
	"deleted_at": null,
	"sha1_hash": "594cc887885c8a9283203f90ea68b870bf878ea5",
	"title": "The Risks of SSL Inspection",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 177548,
	"plain_text": "The Risks of SSL Inspection\r\nBy Will Dormann\r\nPublished: 2015-03-13 · Archived: 2026-04-06 00:13:11 UTC\r\nRecently, SuperFish and PrivDog have received some attention because of the risks that they both introduced to\r\ncustomers because of implementation flaws. Looking closer into these types of applications with my trusty CERT\r\nTapioca VM at hand, I've come to realize a few things.\r\nIn this blog post, I will explain\r\n1. The capabilities of SSL and TLS are not well understood by many.\r\n2. SSL inspection is much more widespread than I suspected.\r\n3. Many applications that perform SSL inspection have flaws that put users at increased risk.\r\n4. Even if SSL inspection were performed at least as well as the browsers do, the risk introduced to users is\r\nnot zero.\r\nBackground\r\nSSL and TLS are used for two primary purposes:\r\n1. Authentication of the server that a client is communicating with.\r\n2. Encrypting data sent between the client and the server.\r\nSome folks may assume that SSL or TLS attempt to achieve the above goals on an end-to-end basis. This is an\r\ninvalid assumption. SSL and TLS can practically achieve secure authentication and encryption only on a point-to-point basis, not an end-to-end basis. What is the difference, you may ask. Let's first look at the case where the\r\npoint-to-point communication is also end-to-end:\r\nThe client has the ability to verify secure communications only with the next point that it is communicating with.\r\nIn the above case, the client establishes an SSL or TLS connection directly with the target system. The client\r\nsoftware verifies that the system that it is connected to has been verified by one of the potentially hundreds of root\r\nhttps://insights.sei.cmu.edu/cert/2015/03/the-risks-of-ssl-inspection.html\r\nPage 1 of 7\n\nCA certificates that may be present on the system. Whether or not the system that is being communicated with is\r\nwhat the user expects is another story.\r\nWhen a user loads a website in his/her browser that should be protected with HTTPS (and subsequently SSL or\r\nTLS), that browser is actually only confirming that the system it is communicating with is providing a certificate\r\nthat is issued by one of the root CAs that the browser trusts. You are implicitly trusting that each root CA has done\r\nits due diligence to verify the identity of the server that you are connecting to. Sometimes root CAs get tricked.\r\nYou are also trusting that each root CA has taken the appropriate steps to protect its own systems. Sometimes root\r\nCAs get compromised. See Moxie Marlinspike's blog post, SSL And The Future Of Authenticity, for more details\r\nabout these problems.\r\nConsider the case of the recent SuperFish and PrivDog vulnerabilities. Those applications install a new trusted\r\nroot CA certificate. Note the specific use of the term \"trusted\" here. We're not talking about anything along the\r\nlines of the web of trust used by the PGP and GPG applications, where the user explicitly indicates a level of trust\r\nwith individual keys. A \"trusted root CA certificate\" is simply one that can be used by client software without\r\ngenerating warnings. It has nothing to do with the \"trust\" that is the confidence a user has in something.\r\nLuckily for the end user, both SuperFish and PrivDog install trusted root CA certificates that have clear\r\nindications that they are from SuperFish and Privdog, respectively. However, there is absolutely nothing\r\npreventing an application from installing a certificate with a more deceptive name, such as \"VeriSign.\"\r\nNow, consider the case where a user with PrivDog or Superfish installed is visiting a site over HTTPS because\r\nhe/she is providing sensitive information, such as a username and password. If his/her browser does not complain\r\nabout the certificate, at best that means that whatever system he/she is talking to was issued by one of the trusted\r\nroot CAs, including SuperFish or Privdog.\r\nIf somebody wants to verify that a certificate is issued by a \"real\" certificate authority, for example by checking\r\nthe issuer's thumbprint, the steps required to do so can vary from browser to browser. Some browsers, such as\r\nMicrosoft Internet Explorer, don't even allow viewing a certificate until after you have accepted it, which can\r\nmake it tricky for even a security professional to determine if he/she is connected to the machine that he/she\r\nthinks.\r\nHost-level software like Superfish or Privdog is just the beginning, though. As it turns out, there are plenty of\r\nnetwork-level applications, devices, and appliances that do SSL inspection. Secure web gateways, firewalls, data\r\nloss prevention (DLP) products, and other applications all seem to have jumped on the SSL inspection\r\nbandwagon. Sure, there may be reasons why a network administrator may want to look into traffic that should be\r\nprotected by SSL or TLS, but what people may not realize are the security impacts of deploying software that does\r\nnot do SSL inspection at least as well as the browsers do. Consider the following diagram:\r\nhttps://insights.sei.cmu.edu/cert/2015/03/the-risks-of-ssl-inspection.html\r\nPage 2 of 7\n\nIn the above scenario, the client can verify only that it is communicating with the SSL-inspecting software. The\r\nclient is unaware of what technique the SSL-inspecting software is using for validating SSL certificates. And\r\nperhaps more importantly, whether there are additional points between the SSL-inspecting software and the target\r\nsystem is impossible for the client to determine. Is there an attacker between the SSL-inspecting software and the\r\ntarget server? The client has no way of knowing. Because of this lack of transparency, the client must assume that\r\nthe SSL inspecting software is doing everything perfectly. Unfortunately, SSL-inspecting software does not do\r\neverything perfectly.\r\nCommon SSL Mistakes\r\nIn our analysis of software that performs SSL inspection, we have observed SSL inspection software make a\r\nvariety of mistakes:\r\n1) Incomplete validation of upstream certificate validity\r\nSome SSL-inspecting software fails to validate the certificates of systems that it connects to. In some cases, the\r\nsoftware may attempt to perform some validation of the certificate, but the validation may be insufficient.\r\nRisks: Clients cannot know if they are connected to a legitimate site or not.\r\n2) Not conveying validation of upstream certificate to the client\r\nIn some cases, the SSL inspection software does perform validation of upstream certificates, but it does not relay\r\nthe results of the validation to the client.\r\nRisks: Clients cannot know if they are connected to a legitimate site or not.\r\n3) Overloading of certificate Canonical Name (CN) field\r\nSome SSL inspecting software attempts to relay the validity of the upstream certificate to the client by way of the\r\nCN field of the certificate. For example, Komodia SSL Digestor changes the CN to begin with \"verify_fail\" if the\r\nserver-provided certificate is invalid for any reason. There are a number of issues with this technique. The most\r\nobvious mistake being that the actual error conveyed to the user usually has nothing to do with why it failed.\r\nRisks: Users of client systems may not know why certificate validation failed, or even if it failed. An attacker may\r\nbe able to specify a Subject Alternative Name field to specify any domain that the certificate specifies it is valid\r\nfor, which results in a browser that does not display a certificate warning.\r\n4) Use of the application layer to convey certificate validity\r\nTo relay the validity of the certificate to the client, some SSL inspectors provide web content (e.g. HTML) to the\r\nhttps://insights.sei.cmu.edu/cert/2015/03/the-risks-of-ssl-inspection.html\r\nPage 3 of 7\n\nclient, describing what is wrong with the certificate. The normal mechanisms through which client software\r\nascertains and displays certificate validity may still indicate that the certificate is fine.\r\nRisks: Not everything that accesses data using HTTPS is a human using a web browser. For example, the client\r\nmay be an application that communicates with a server using JSON data. This flaw also causes inconsistent use of\r\nSSL validity indicators (e.g., \"Where do I look for the padlock again?\").\r\n5) Use of a User-Agent HTTP header to determine when to validate a certificate\r\nSome software will selectively decide when to validate upstream certificates based on the User-Agent HTTP\r\nheader provided by the client. This technique is likely used in conjunction with the technique described above\r\nwhere certificate validity is conveyed in the application layer.\r\nRisks: Not every web client may receive certificate validation. Various web browser versions and non-browser\r\nsoftware may be exempt from validation.\r\n6) Communication before warning\r\nUpon detecting a certificate error, some SSL inspection applications will send the client's request to the server\r\nprior to presenting a warning to the user.\r\nRisks: An attacker still may be able to view or modify sensitive data.\r\n7) Same root CA certificate\r\nSome SSL inspection applications use and install the same trusted root CA certificate for each installation of the\r\napplication.\r\nRisks: An attacker may be able to extract the private key from the software and sign all visited sites with the\r\nuniversally-trusted root CA certificate.\r\nConsider the case where an SSL inspection application performs flawlessly. That is, it has none of the above seven\r\nflaws, or flaws similar to them. It validates the identity of the upstream server based on its own trusted root CA\r\ncertificate store. However, the client has no visibility into what root CAs the SSL inspection software trusts, in\r\nparticular if it's a separate device on the network. The use of SSL inspection software reduces or completely\r\nprevents clients from successfully validating the identity of the servers that they are communicating with.\r\nGiven the architecture of SSL and TLS, users have a difficult enough time making a security decision based on the\r\ninformation provided to them. Once the concept of SSL inspection is thrown into the mix, it only makes the\r\ndecision more difficult.\r\nPotentially Affected Software\r\nBy performing a web search for \"ssl inspection,\" we were able to construct a list of applications that may be\r\naffected by a number of the above-outlined vulnerabilities. However, due to time and resource constraints, we\r\nhave not been able to acquire or test a number of these applications, so we are soliciting feedback from the\r\ncommunity to ascertain their status. Just because a product is listed, does not necessarily mean that it contains any\r\nof the seven vulnerabilities above. The list of applications possibly affected includes the following:\r\n1. A10 vThunder\r\nhttps://insights.sei.cmu.edu/cert/2015/03/the-risks-of-ssl-inspection.html\r\nPage 4 of 7\n\n2. Arbor Networks Pravail\r\n3. Baracuda Web Filter\r\n4. BASCOM School Web Filter\r\n5. Bloxx Web Filter\r\n6. Blue Coat SSL Visibility Appliance\r\n7. Check Point Data Loss Prevention (DLP), Anti Virus, Anti-Bot, Application Control, URL Filtering, Threat\r\nEmulation and IPS.\r\n8. Cisco ScanCenter\r\n9. Citrix NetScaler AppFirewall\r\n10. Clearswift SECURE Web Gateway\r\n11. ContentKeeper\r\n12. Cymphonix Internet Management Suite\r\n13. Dell SonicWALL\r\n14. EdgeWave iPrism Web Security\r\n15. ESET Smart Security\r\n16. F5 BIG-IP\r\n17. Fortinet FortiGate\r\n18. Fidelis Security XPS\r\n19. Finjan Vital Security (pdf)\r\n20. GFI WebMonitor\r\n21. GigaMon GigaSmart\r\n22. IBM Security Network Protection\r\n23. iboss Web Security\r\n24. Imperva Incapsula\r\n25. iSHERIFF Cloud Security\r\n26. Juniper IDP devices\r\n27. Kaspersky Anti-Virus\r\n28. Komodia SSL Decoder\r\n29. M86 Secure Web Gateway (pdf)\r\n30. McAfee Web Gateway and Firewall Enterprise (pdf)\r\n31. Microsoft Forefront TMG\r\n32. NetNanny\r\n33. NextGig Netronome\r\n34. Optenet WebFilter (pdf)\r\n35. Palo Alto PAN-OS\r\n36. Panda Cloud Internet Protection\r\n37. PrivDog\r\n38. Radware AppXcel\r\n39. SafeNet eSafe Web Security Gateway\r\n40. Sangfor IAM (pdf)\r\n41. Smoothwall Secure Web Gateway\r\n42. Sophos Cyberoam\r\nhttps://insights.sei.cmu.edu/cert/2015/03/the-risks-of-ssl-inspection.html\r\nPage 5 of 7\n\n43. Sourcefire SSL Appliance\r\n44. Squid\r\n45. Symantec Web Gateway\r\n46. Thomason Technologies Next Gen IPS\r\n47. Trend Micro Deep Security (pdf)\r\n48. Trustwave WebMarshal, Secure Web Gateway\r\n49. Untangle NG Firewall\r\n50. Venafi TrustAuthority\r\n51. VSS Monitoring vInspector (pdf)\r\n52. WatchGuard HTTPS Proxy\r\n53. Wavecrest CyBlock\r\n54. WebSense Content Gateway\r\n55. WebTitan\r\n56. Qbik WinGate\r\n57. WolfSSL SSL Inspection\r\n58. Zscaler\r\n59. ZyXel Firewall\r\nAgain, just because a product is listed, does not mean that it is necessarily vulnerable.\r\nConclusion\r\nSSL and TLS do not provide the level of end-to-end security that users may expect. Even in absence of SSL\r\ninspection, there are problems with how well browsers are conveying SSL information to users. The fact that \"SSL\r\ninspection\" is a phrase that exists, should be a blazing red flag that what you think SSL is doing for you is\r\nfundamentally broken. Compounding the problem are the mistakes that SSL inspection software authors are\r\nmaking.\r\nSystem administrators may wish to reassess whether they want to deploy SSL inspection capabilities in their\r\nenvironment. CERT Tapioca can be used to verify that the SSL inspection solution being used is doing its due\r\ndiligence to minimize the increased risk to the users. At the very least, system administrators could contact the\r\nvendors of SSL inspection software to have them confirm the proper configuration options and behaviors.\r\nIf you are aware of products that do SSL inspection but are not listed above, or if you have details about which\r\nproducts contain which vulnerabilities, please send us feedback.\r\nUpdate (March 22, 2017)\r\nUS-CERT has published Technical Alert TA17-075A about this topic. One aspect of this situation that has changed\r\nsince the first publication of this blog entry in 2015 is the existence of the badssl.com website. This site makes it\r\neasier to test the effects of HTTPS interception, and it also makes it possible to test HTTPS behaviors much more\r\nthoroughly than Tapioca allows. To test your own HTTPS inspection environment:\r\n1. Visit www.badssl.com using a browser that has direct (non-intercepted) internet connectivity.\r\nhttps://insights.sei.cmu.edu/cert/2015/03/the-risks-of-ssl-inspection.html\r\nPage 6 of 7\n\n2. Visit each of the red test sites listed to confirm your browser's behavior. In many cases, a modern browser\r\nwill refuse to display the red-linked sites.\r\n3. Complete the same tests on the same browser version, but in a network configuration where HTTPS traffic\r\nis being intercepted.\r\n4. Compare how the browser behaves in a configuration where HTTPS interception is performed against the\r\nbehavior where the browser has a non-intercepted internet connection. If an intercepted browser allows\r\nconnectivity to any of the tests that are blocked in non-intercepted mode, this is an indication of a weakness\r\nintroduced by HTTPS interception.\r\nSource: https://insights.sei.cmu.edu/cert/2015/03/the-risks-of-ssl-inspection.html\r\nhttps://insights.sei.cmu.edu/cert/2015/03/the-risks-of-ssl-inspection.html\r\nPage 7 of 7",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://insights.sei.cmu.edu/cert/2015/03/the-risks-of-ssl-inspection.html"
	],
	"report_names": [
		"the-risks-of-ssl-inspection.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775439134,
	"ts_updated_at": 1775791196,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/594cc887885c8a9283203f90ea68b870bf878ea5.pdf",
		"text": "https://archive.orkl.eu/594cc887885c8a9283203f90ea68b870bf878ea5.txt",
		"img": "https://archive.orkl.eu/594cc887885c8a9283203f90ea68b870bf878ea5.jpg"
	}
}