원문: The Risks of SSL Inspection

Some folks may assume that SSL or TLS attempt to achieve the above goals on an end-to-end basis. This is an invalid assumption. SSL and TLS can practically achieve secure authentication and encryption only on a point-to-point basis, not an end-to-end basis.

지점간 연결(point-to-point)와 최종 목적지간 연결(end-to-end)의 보안성은 서로 다른 문제인데, 잘 생각해보지 않으면 차이점을 눈치채기 힘들다. 실제로 인터넷에서 연결 경로 어디에 SSL 트래픽을 검사하는 소프트웨어나 장비가 있더라도 클라이언트 입장에서 이것을 알 수 없다.

SSL, TLS 연결을 검사하는 소프트웨어나 장비의 SSL, TLS 탐지 기능에 결함이 있어서 사용자들을 위협에 노출시킬 수 있다는 것도 또 다른 문제.

Common SSL Mistakes

In our analysis of software that performs SSL inspection, we have observed SSL inspection software make a variety of mistakes:


1) Incomplete validation of upstream certificate validity Some SSL-inspecting software fails to validate the certificates of systems that it connects to. In some cases, the software may attempt to perform some validation of the certificate, but the validation may be insufficient.

Risks: Clients cannot know if they are connected to a legitimate site or not.

2) Not conveying validation of upstream certificate to the client In some cases, the SSL inspection software does perform validation of upstream certificates, but it does not relay the results of the validation to the client.

Risks: Clients cannot know if they are connected to a legitimate site or not.

3) Overloading of certificate Canonical Name (CN) field Some SSL inspecting software attempts to relay the validity of the upstream certificate to the client by way of the CN field of the certificate. For example, Komodia SSL Digestor changes the CN to begin with “verify_fail” if the server-provided certificate is invalid for any reason. There are a number of issues with this technique. The most obvious mistake being that the actual error conveyed to the user usually has nothing to do with why it failed.

Risks: Users of client systems may not know why certificate validation failed, or even if it failed. An attacker may be able to specify a Subject Alternative Namefield to specify any domain that the certificate specifies it is valid for, which results in a browser that does not display a certificate warning.

4) Use of the application layer to convey certificate validity To relay the validity of the certificate to the client, some SSL inspectors provide web content (e.g. HTML) to the client, describing what is wrong with the certificate. The normal mechanisms through which client software ascertains and displays certificate validity may still indicate that the certificate is fine.

Risks: Not everything that accesses data using HTTPS is a human using a web browser. For example, the client may be an application that communicates with a server using JSON data. This flaw also causes inconsistent use of SSL validity indicators(e.g., “Where do I look for the padlock again?”).

5) Use of a User-Agent HTTP header to determine when to validate a certificate Some software will selectively decide when to validate upstream certificates based on the User-Agent HTTP header provided by the client. This technique is likely used in conjunction with the technique described above where certificate validity is conveyed in the application layer.

Risks:Not every web client may receive certificate validation. Various web browser versions and non-browser software may be exempt from validation.

6) Communication before warning Upon detecting a certificate error, some SSL inspection applications will send the client’s request to the server prior to presenting a warning to the user.

Risks: An attacker still may be able to view or modify sensitive data.

7) Same root CA certificate Some SSL inspection applications use and install the same trusted root CA certificate for each installation of the application.

Risks: An attacker may be able to extract the private key from the software and sign all visited sites with the universally-trusted root CA certificate.


Consider the case where an SSL inspection application performs flawlessly. That is, it has none of the above seven flaws, or flaws similar to them. It validates the identity of the upstream server based on its own trusted root CA certificate store. However, the client has no visibility into what root CAs the SSL inspection software trusts, in particular if it’s a separate device on the network. The use of SSL inspection software reduces or completely prevents clients from successfully validating the identity of the servers that they are communicating with.

Given the architecture of SSL and TLS, users have a difficult enough time making a security decision based on the information provided to them. Once the concept of SSL inspection is thrown into the mix, it only makes the decision more difficult.

7번이 SuperFish에서 발견된 문제점이다. SSL과 TLS가 나의 트래픽을 안전하게 하리라는 미신은 갖지 않는 게 좋다.