HTTPS Inspection and your PKI

Hey everyone.  This is Wes Hammond from Premier Field Engineering and let me say first, Welcome to my new blog.  My first topic is one that I have been getting alot of questions on lately HTTPS inspection.  Engineers want to know how they work and their relation to their existing PKI.  So here are my thoughts...

First, the devices that perform this work similarly to a man in the middle attack so please take note: Microsoft does not condone or support the use of these appliances for this reason.  Second, these devices typically require a CA certificate to function.  To understand why let’s take a look at a typical TLS handshake and then one using the inspection device inserted into the conversation.

Typical TLS handshake

1. Client Hello – Client sends initial request to start TLS
2. Server Hello – Server responds to client request and includes its digital certificate.

HTTPS Inspection – TLS handshake

1.  Client Hello – Client sends initial request to start TLS
2. Inspection device repeat – Connection will be relayed through the inspection device to the web server
3. Server Hello – Server responds to client request and includes its digital certificate
4. Inspection Device Capture - The inspection device will issue a certificate to the website the client visited and pass this certificate to the client in place of the one the server sent.

A moment ago I mentioned these devices need a CA certificate to function.  The reason for this is the device functions like a certification authority, issuing certificates ad-hoc to the sites your users visit.  This CA certificate has to chain up to a trusted root just like any other certificate.  So now you may be faced with some options.  Do you issue a self-signed CA certificate to these devices and distribute it to your clients like any other Root CA in you
manage?  Or do you issue a subordinate CA certificate to the device that chains up to an already trusted internal root CA?  Decisions, decisions….

Let me give you some more to think about.  The CA certificates on these servers are often unconstrained and can be used for any purpose whatsoever (SSL  certificates, Code Signing Certificates, Client Authentication, etc) if they were to become compromised.  Oh, and they are trusted by every machine in your business…..think happy thoughts.  While this might be okay for some smaller organizations with a limited footprint some large enterprise customers may want to limit this risk as much as possible.

Here are some sample solutions:

1.  Issue a self-signed CA certificate and distribute it to your clients through group policy.  This makes the device a root CA in the eyes of your clients.  If you need to remove the trust you can simply remove the certificate from the group policy and the clients will remove it from their trusted stores on the next update.  The only CON I have here is that the devices generally do not constrain the certificate to certain usage or EKU (Enhanced Key Usage).  We will talk more about this
in a little bit.

2.  Issue the inspection devices certificate from a root or intermediate CA.  I generally do not recommend this unless you have a good reason for it.  The positives here are that it does chain up to an already existing and trusted root, and you have the ability to restrict the usage of the certificate.  However, root and intermediate CA’s are generally offline and do not update their CRL’s frequently so it may take an extended amount of time for clients to learn of the inspection devices certificate revocation should it become compromised and revoked.

3.  Issue the inspection devices certificate from an Issuing Subordinate CA.  This is the most practical I have found through my experience. The positives are, depending on how frequently you publish a CRL you can revoke the inspection devices certificate if needed.  Since the subordinate CA publishes a CRL more
often than offline CA (Root or Intermediate) the clients will learn of the inspection devices certificate revocation more quickly and will no longer accept
certificates signed by it.  You also can use certificate templates to limit the usage of the inspection devices certificate.  The only negative at this
level is generally the validity period of the inspection devices certificate which can vary from environment to environment based on design decisions.  

Some additional security options to limit risk

Hardware Security Modules (HSM's)

I have found that some of the inspection devices can hook into HSM’s for key protection.  This limits the access to the private key material used to sign the certificates issued by the device.

Limiting Enhanced Key Usage:

This is where I talk about constraints again.  If you don’t know what they are see my previous article here.  The inspection device typically needs to
issue certificates for OID 1.3.6.1.5.5.7.3.1 (server authentication).  So consider constraining the inspection devices CA certificate to issuing certificates with the Server Authentication EKU

Basic Constraints:

The inspection device does not need to issue additional subordinate CA’s.  So consider using the basic constraints extension to prevent it.  Using a path length of 0 will get this done.

Sample Code:

Below is a sample policy INF that when applied to a CSR generated by inspection devices will modify the resulting certificate to have a basic constraint path length equal to 0 so the inspection device certificate can no issue subordinates.  It will also set enhanced key usage to Server Authentication so the inspection CA certificate can only be used to sign certificates that leverage Server Authentication.

[Version]Signature= "$Windows NT$"[ApplicationPolicyStatementExtension]Policies = AppSeAuthPolicyCRITICAL = FALSE[AppSeAuthPolicy]OID = 1.3.6.1.5.5.7.3.1 ; Server Authentication[BasicConstraintsExtension]PathLength = 0Critical = Yes

 

Applying a Policy to a CSR

certreq -policy "Fabrikam Internal.req" policy.inf "Fabrikam Internal-modified.req"

Creating a Subordinate CA certificate Template that includes Basic Constraints and Server Authentication EKU

Open the certificate template manager

Duplicate the Subordinate Certificate Authority template

Go to the extensions tab of the new template, edit the
following two items so they resemble the following:

Application Policy: Server Authentication EKU

Highlight application policy extension and hit edit.

Click add and select Server Authentication, click ok.

Verify the changes made to the application policy.

 

 

Basic Constraints Extension: Path Length Constraints

Highlight Basic Constraints extension and hit edit. *Note the current description

Check the box for “Do not allow subject to certificates to other CAs”

Verify the changes made to the basic constraints extension.

 

 

Submitting the CSR to a Standalone CA or Enterprise CA via command line

certreq -submit -attrib certificatetemplate:SubCA “Fabrikam Internal-modified.req”

*Note: The certificate template name may vary if you are using an enterprise CA and a custom template.

Submitting the CSR to a Standalone CA or Enterprise CA via Web Enrollment

Another method that can be employed to request these certificates is Web Enrollment.  Using this method you can request the certificate from a standalone of enterprise CA and even select the template from a GUI if it is applicable.

Verifying and Approving the Request

After you request the certificate it should go into the
pending status and you can review it.  Verify
the following items if you wish to use EKU or Basic Constraints or Both:

Application Policies should include: Server Authentication

Basic Constraints should contain Path Length=0 and should be a critical extension

If these 2 items are present you can issue the certificate and use it on the inspection device. Congratulations you have limited the functionality of your inspection
device certificate and reduced risk.

Comments

• Anonymous
  March 12, 2017
  Your policy INF looks malformed
  • Anonymous
    March 13, 2017
    Hmmm......I think it was just the page formatting. Hopefully I fixed it.
• Anonymous
  May 12, 2017
  "However, root and intermediate CA’s are generally offline and do not update their CRL’s frequently"....thinking about this :Why we make intermediate CA as offline? I believe generally intermediate used to be online and offline root CA. And in that case providing a cert from the issuing CA will be a good option?Please correct me if this is not correct.
  • Anonymous
    July 18, 2017
    No, Wes is right! Intermediate CAs, like root CAs, don't have much work to do! It is the issuing CAs which sign operatively the CSRs.For security reasons both root CAs and intermediate CAs should be kept shut down.
  • Anonymous
    July 18, 2017
    Intermediate (Policy CA's) are not used to issue End-Entity certificates so the rule of thumb is they should be standalone, offline, and hopefully HSM protected.
• Anonymous
  July 07, 2017
  In many circumstances being able to inspect SSL traffic is a security risk. For instance accessing a banking site. Or the risk of an attacker being issued a trusted issuing cert and intercepting traffic.Using IIS is there a way to "pin" certificates for services such that attempts to proxy the traffic will fail? Or any other method for selected HTTPS services to stop this?
  • Anonymous
    July 18, 2017
    No there isn't. This has to be done on the client side. Windows 10 supports certificate pinning which allows you to do just this. Older clients such as win7 can use EMET to do cert pinning for them.