A quick look at the on-the-fly created server certificate by Forefront TMG 2010 RTM’s Outbound HTTPS Inspection

One interesting aspect about Forefront TMG 2010 RTM’s Outbound HTTPS Inspection is the on-the-fly created server certificate.
Forefront TMG connects to the real server, gets its certificate, inspects it, “clones” it and presents to the client this “cloned” certificate. The client accepts this certificate as was issued by a trusted CA(TMG’s HTTPS Inspection certificate).
So let’s have a look at the “cloned” certificate.

• it tends to “have” the original hash algorithm used in signing the original server’s certificate.
  
  
• the expiration date of this certificate is modified(for possibly why see bellow).
  
• whatever was the size of the original RSA key from the real server’s certificate(512 bits, 1024 bits, 2048 bits), now is set to 2048 bits-unless you’ve interfered-(it uses the public RSA key from TMG’s HTTPS Inspection certificate, which by default has 2048 bits).
  
• the Key Usage on the cloned certificate is (apparently) set to Digital Signature, Key Encipherment (a0), either if on the original certificate contained more options, or was not set.
  
  vs
  
• there is a similar story with the Extended Key Usage on the cloned certificate, which is (apparently) set to Server Authentication (1.3.6.1.5.5.7.3.1), even if on the original certificate it contained more options.
  
  vs
  
• as you can see from above(there is another example bellow), in the original certificate EKU field, the 2.16.840.1.113730.4.1 OID is present, which means this is a Server Gated Cryptography (SGC) certificate(actually this OID is for Netscape "Step Up", Microsoft SGC OID should be 1.3.6.1.4.1.311.10.3.3, both are removed if present on the original certificate so the cloned certificate will not have them).
  In the past, the US government placed restrictions on the export of what was called 'strong encryption' software. Some browser versions were restricted to 40 bit and 56 bit encryption, and did not support 128 bit encryption(actually they support it, but it was “hidden”). Some of these browsers were able to recognize that the server used a Server Gated Cryptography (SGC) certificate and so they were able to use 128 bit encryption with that server. Such a server could be a bank web server.
  SSL/TLS cipher suites using weak or export encryption algorithms(40-bit, 56-bit) are disabled by default on TMG for HTTPS Inspection and not only(either on Windows Server 2008 SP2 or on Windows Server 2008 R2). This is also true for most modern browsers. 40 bit or 56 bit encryption is considered too weak these days.
  
• the Basic Constraints extension on the cloned certificate  is (always) set to Subject Type=End Entity, even if the original server certificate did not have such constraints. Setting this extension like so, basically means that  the subject is not a CA(thus cannot sign certificates). This is a preventive measure.
  
  vs
  
• As a side note, TMG’s default HTTPS Inspection certificate, root certificate(if you are using the one generated with TMG’s GUI), has the Basic Constraints Path Length Constraints set to 0, which means that the number of CA certificates that are allowed in the chain below the root is zero.
  
• if some extensions are marked as critical on the original certificate, on the cloned one they might not be marked as critical anymore. You can view this aspect in some of the above screen shots.
• there are no CDP(CRL Distribution Point) or AIA(Authority Info Access) fields on the cloned certificates, TMG removes the original CDP or AIA fields(they are no longer applicable(valid) for the new on-the-fly temporary server certificate.). We saw this aspect here.
• the original Certificate Policies is still present on the cloned certificate. Since the cloned certificates are end entity certificates, the information found under the Certificate Policies indicates the policy under which the certificate has been issued and the purposes for which the certificate may be used. Bellow the Policy Identifier=2.16.840.1.114413.1.7.23.1, according to GoDaddy’s CPS(Certification Practice Statement) means a Medium Assurance Certificate. Whatever it says on the URL linked bellow in the original Certificate Policies no longer applies to the cloned certificate.
  
• I was not able to connect to a secure web server using a DSA certificate(containing a DSA key, signed with sha1DSA, anyway, who uses anymore such a server certificate ?), this(see bellow) was logged by TMG. Remember that by default TMG’s HTTPS Inspection certificate uses a RSA key, but it would not be required(IMHO) to recreate per se the original server certificate(which in this case is signed with DSA). Apparently TMG does respond to client’s CONNECT request with a HTTP/1.1 200 Connection established message, and when the client issues the Client Hello message, it will RST the connection.
  
  
  

Extended Validation(EV) certificates vs TMG’s Outbound HTTPS Inspection
An Extended Validation(EV) certificate is a certificate issued in conformance with the guidelines defined by the CA Browser Forum. You may like to read Guidelines For The Issuance And Management Of Extended Validation Certificates(as writing version 1.2, get it from here).
An EV certificate provides assurance that a domain is owned and a website is operated by a legitimate organization.
The end user typically associates a web site using an EV certificate with a special visual element displayed by the browser(this would vary depending what browser the user uses). This may mean for the user that the site is trustworthy(or maybe not the site, rather the connection), an extra “assurance” regarding the identity of the web site.
The Outbound HTTPS Inspection should be, by definition, incompatible with EV certificates. Incompatible does not mean that it technically cannot work, that is, if a secure web site made the browser’s address bar green(IE8), the same visual effect cannot be achieved with the Outbound HTTPS Inspection in place, as based on the client’s configuration such a thing may be trivial to do.
The idea is you can’t preserve endpoint identity when someone(TMG) unrelated to the original endpoint is MITM-ing you(which actually is what the Outbound HTTPS Inspection does), thus the little “extra” provided by EV certificates becomes somehow pointless in case of a MITM that still makes the bar green(IE8).

1. Which CA can issue Extended Validation(EV) certificates ?
   Any CA, however to issue certificates that comply with the standard the CA must adopt the extended certificate validation practices and pass an audit.
2. Who can obtain an Extended Validation(EV) certificate ?
   EV certificates can only be issued to private organizations and government entities that satisfy certain requirements. EV certificates cannot, as writing, be issued to individual entities.
3. How is the browser able to recognize EV certificates ?
   There isn’t anything special about an EV certificate, underneath it’s a “regular” certificate. At a glance, to point some aspects, within the Subject field, some subjects are required:
   - Organization name
   - Domain Name
   - Business Category(OID: 2.5.4.15)
   - Jurisdiction of Incorporation or Registration(jurisdictionOfIncorporationCountryName(OID: 1.3.6.1.4.1.311.60.2.1.3), jurisdictionOfIncorporationStateOrProvinceName(if required, OID: 1.3.6.1.4.1.311.60.2.1.2), jurisdictionOfIncorporationLocalityName(if required, OID: 1.3.6.1.4.1.311.60.2.1.1)) 
   - Registration Number(serialNumber(OID: 2.5.4.5)) 
   - Physical Address of Place of Business(City, state and country).
   This certificate must contain the CRL Distribution Points extension(OCSP AIA extension should be supported, but currently is not a must), so the client to be able to check the certificate revocation status(if OCSP is supported, the client, in case of an EV certificate may check all the certificates(including CA certificates) in the chain with OCSP assuming the appropriate OCSP AIA extension is present on those certificates). For example, IE8 won’t make the bar green for web site using an EV certificate if it cannot do a revocation status check or, alternatively, the SmartScreen Filter is enabled.
   What mainly makes a difference for the (most) browsers, is the Certificate Policies extension field. Each issuer has its own EV object identifier (OID) in this field to identify EV certificates issued by it, and the EV OID is documented in the issuer's CPS(Certification Practice Statement). Bellow, based on the EV OID we can tell this is a certificate issued by VeriSign(there is a VeriSign intermediate CA especially used for issuing EV certificates that chains to a root CA). The subordinate CAs that are controlled by the root CA may contain the special anyPolicy identifier(OID: 2.5.29.32.0)).
   The browser binds the EV OID with a root CA’s unique identifier(usually the SHA-1 fingerprint of the root CA certificate).
   
   
   
   As we saw above, the original Certificate Policies is present on the cloned certificate. But that won’t make the browser(behind TMG) display a green bar(IE8) or the specific visual element for that browser when an EV certificate is spotted. And this (mainly) is due to that bind we spoke above.
   If you want to add a new root for EV, you need to patch somehow the browser(if possible), or if you have access to the source code, to make the needed modification, build a new version and install this new version. Usually, the owner of the root will submit to add for EV its root and provide the needed documentation, the request will be analyzed by the application vendor, if it’s OK, it will be completed and you will notice the specific visual element for the browser you use when an EV certificate is used by the server. Such requests can be seen here and here on Google’s web site. Additionally you may like to check this resource from Mozilla.
   The situation may be “special” for IE8, as we saw here.
   
4. Should you exclude from TMG’s Outbound HTTPS Inspection all the web sites using EV certificates ?
   No. As we speculated above, an EV certificate does not automatically mean the web site using it is trustworthy(which is a lame and general word), rather the connection is (supposed) to be so, you are connected to the correct web site.
   While such certificates might be used by financial institutions, you don’t actually exclude online banking from the Outbound HTTPS Inspection because it uses an EV certificate(some of them won’t use an EV certificate), rather because of the privacy issues and the sensitivity of such traffic.
   It’s true that users might complain that their favorite web site does not “go green” behind TMG, but simply put, if you make that site “green” while applying Outbound HTTPS Inspection, although they(users) might not realize, there is no identity assurance in that.

As an off-topic note, probably you can make Firefox with the help an add-on to display something when a certificate signed by TMG’s HTTPS Inspection certificate “is used” by the server, thus have a way within the browser for users to notice that HTTPS Inspection is applied(without the use of the TMG Client).

Why does the validity period of the servers’ certificates looks “different” with TMG on the path doing Outbound HTTPS Inspection ?
Example:

• without TMG on the path:
  

vs

• with TMG on the path doing Outbound HTTPS Inspection:
  

Note that above I’ve accessed for the first time through TMG doing Outbound HTTPS Inspection this web site around December 28, 2009, 8:17. If we look carefully at the expiration date, we might see that it will expire in 24h from the moment I’ve accessed this site.

As I’m not in Microsoft shoes I would say(guess) that one reason for this would be security. Since it’s a temporary certificate, it should not last too long.
Remember that here I’ve said that “basically speaking there is no revocation check that the client can make(from a certain point of view)” ?
Well, if we keep in mind this short expiration period, in the real world, practically this temporary certificate will expire faster than a fresh CRL will be downloaded or a fresh OCSP response will be obtained. Clients may cache CRLs and OCSP responses till they expire, usually their validity is about a few days(note that a browser may decide how long to cache an OCSP response, to cache it in process memory(so closing and opening the browser will cause the deletion of that cache), but that does not mean the OCSP server would not return the same OCSP response, for example if I use Firefox 3.5 on Windows 7 and access gmail, close the browser and again access gmail, if I take Wireshark traces for both attempts, I can see that each time an OCSP request is made, but the OCSP response is the same, see the bellow screen shots, it depends how the OCSP responder “gets/updates its info”).

Why does, sometimes, in Opera(10.01) without TMG on the path doing Outbound HTTPS Inspection when moving the mouse over the padlock some different parameters are shown compared to what is shown when clicking the padlock while with TMG on the path doing Outbound HTTPS Inspection when moving the mouse over the padlock same parameters are shown compared to what is shown when clicking the padlock ?
To picture this, let’s go to such a site(PayPal in this example, let’s forget a second about PayPal’s EV certificate and that the web site is PayPal):

• with TMG on the path doing Outbound HTTPS Inspection:
  
  

vs

• without TMG on the path:
  
  

While this may relate to TMG’s Outbound HTTPS Inspection, is rather a browser behavior. If you view the source code for the web page(s) displayed by your browser, you may notice that elements from other sources(domains, example: paypalobjects.com, etc.) are displayed over SSL/TLS(separate connections). When you click on the padlock, you get details for the connection of the link you’ve typed(maybe not the most fortunate expression), while when you move the mouse over the padlock Opera may display information about one of the other SSL/TLS connections. Above, without TMG on the path, moving the mouse over the padlock, it says something about RC4(sometimes it may say AES 256).
With TMG on the path doing Outbound HTTPS Inspection, the SSL/TLS connections about which your browser displays details are between TMG and the browser, thus although still separate connections(click the padlock vs move the mouse over the padlock), they may use the same cipher suite(TMG’s preferred cipher suite), which is an AES 128-bit one.

To build on this momentum, you must note that the SSL/TLS connection’s details(the connection between TMG and the browser) that your browser displays with TMG on the path doing Outbound HTTPS Inspection, may be different than the details of the SSL/TLS connection between TMG and the real server.
Thus (some) mechanisms the browser may have in place for assessing the security level of the SSL/TLS connection, may no longer apply. For example Opera does not allow without a warning a secure web server with a (weak) public RSA key of 512 bits(which no longer provides appropriate security these days). With TMG on the path doing Outbound HTTPS Inspection(TMG not enforcing any minimum key size limits to avoid weak keys in the server’s certificate), Opera sees the server’s certificate as having a 2048-bit RSA key:

• without TMG on the path:
  

vs

• with TMG on the path doing Outbound HTTPS Inspection: