Category Archives: Standards

The (soon to be) not-so Common Name

6 Replies

If you are reading this post you are probably familiar with the use of digital certificates in SSL even if you are you may not be familiar with their history. Before we go there though we should start with what, at its core a digital certificate actually is.

Fundamentally a digital certificate is a binding of entitlements and constraints to a key, in other words they say things like “The holder of the private key associated with this certificate can rightfully use the name Ryan Hurst when signing emails”.

When originally conceived they were to be used to help bind subjects (people and resources) to their representations in directories. This is why the Subject Name in a certificate is structured as a Distinguished Name (DN) as this is how a directory uniquely identify a subject.

This makes sense when looking up an encryption key for a user in an enterprise directory but not so well on the Internet where there is no global directory of users.

This brings us to SSL, it was introduced in the mid 1990s and at the time nearly every large enterprise was already deploying Directories and Certificate Authorities as part of their identity management frameworks. The technology of X.509 was tested, broadly accepted and fit the bill for the problem the designers of the protocol had so they included it as is.

At the time there was only one way to represent concept of a subject of a certificate and that was the Common Name (CN) so they chose to put the DNS name of the SSL server there. This was technically acceptable but was a re-purposing of a field that was really intended for a users actual name.

After SSL was finalized the IETF released their profile of X.509 for use on the Internet this standard introduced the concept of a Subject Alternative Name (SAN) where you can put names that are not associated with a directory. The problem is that ship had sailed, by the late 90s when this was standardized everyone had already settled on using the Common Name.

This led us down a bad path, first of all many servers (especially today) have multiple DNS names and application that supported only the Common Name field couldn’t work with a single certificate with more than one DNS name in it. This was addressed in the short term by using a single certificate for each DNS name but this came at a high cost, we also needed to use a single IP address for each domain name.

Another problem with this approach is applications never really knew what to expect in the Common Name field. Is the value in that field a person’s name or is it a DNS name? This is a problem because often times there are rules you need to use to validate a piece of data before using it and this is especially true for DNS names.

For these reasons (and more) since at least 1999 (when RFC 2459 was standardized) we have been on a slow path to moving away from the use of Common Names for domain names to using Subject Alternative Names.

Fast forward to 2012 some Stanford researchers publish a paper titled “The most dangerous code in the world: validating SSL certificates in non-browser software” which identifies a bunch of applications who fail to do the most basic certificate validation tasks correctly and as a result are the source of a bunch of security vulnerabilities.

These applications gave their users a false sense of security not out of malice but as a result of a lack of understanding of the technology they used to deliver on that promise. A big part of that is the complexity 18 years of technological evolution carries with it.

To address this a number of things need to change but one of the most immediate changes is what that the definition of what constitute a “valid” SSL certificate is changing to make the rule-set a little simpler for the application developer and to rule out options that are no longer considered good practice.

We see this happening in a few ways. First the CA/Browser Forum has worked with Browsers to define a set of Baseline Practices that all Certificates must meet, we are also seeing Browsers doing sanity checks to ensure these practices are in-fact followed.

These baseline requirements mandate that certificate authorities always include at least one Subject Alternative Name in the SSL certificates they issue, this means that today an application doesn’t need to look in both the Common Name and the Subject Alternative Name they only need to check the latter.

Currently most Certificate Authorities will include the first DNS Name from the Subject Alternative Name in the Common Name field also but this is done primarily for legacy reasons and at some point in the not so distant future will stop.

When it does certificates will be a little smaller and developers lives will be a little easier.

Ryan

Resources

· Baseline Requirements

· Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile

· Microsoft Security Advisory: Update for minimum certificate key length

Abstract: Using least privileged design principals to improve trust in the online marketplace

Leave a reply

Weekends, they are overrated 🙂

Tomorrow is the cut-off for submissions for the NIST workshop on “Workshop on Improving Trust in the Online Marketplace” to be held April 2013 and I have spent part of the day thinking about what talks might be interesting. I have already submitted one on “Revocation reality and the path to becoming effective” but I also wrote this one up and I might submit it also, posting here so I can get a little feedback before the submission deadline.

In 2010 security researchers with the EFF collected the certificates of all of the publicly-visible SSL certificates on the IPv4 internet and published their analysis and data-sets from their research. This work made it clear to the world how extensively PKI is used to facilitate commerce on the web but it also raised he concern that there were as many as 650 organizations capable of issuing publicly trusted certificates on the internet.

While this conclusion is exaggerated as many of those certificates and keys are in-fact operated by the same organizations that their certificates are ultimately issued by, the conclusion that there has been an un-needed expansion of the number of keys that are technically trusted to issue certificates for SSL for the entire Internet is sound.

To address this problem one of the steps that is needed is the application of least privilege principals to how one designs and manages publicly trusted keys and certificates. Thankfully in the late 90’s the foundation for addressing much of this problem was developed as a means to enable the Federated PKI in use by the U.S. Federal Government.

For the last year we have been working to broadly deploy X.509 Name Constraints’ along with other least privilege design principals to our customers PKIs both internally managed by our own staff as well as those on premise. This talk will explore these concepts, the client support for them, the challenges we have experienced in their deployment and identify the remaining issues that must be addressed to obtain the full benefits of this approach.

Abstract: Revocation reality and the path to becoming effective

1 Reply

Just submitted my first abstract for the NIST workshop on “Workshop on Improving Trust in the Online Marketplace” in April, the title of the talk is “Revocation reality and the path to becoming effective”, the abstract of which is:

 

The concept of certificate revocation is core to the X.509 trust model however 18 years after its introduction the reality is as implemented and deployed it falls short of its promise to enable an issuer certificate issuers to protect relying parties from malicious actors and miss-issuance

This talk will discuss the findings of a project where I have observed the behavior (https://revocation-report.x509labs.com), up time and performance of revocation repositories for a number of commercial Certificate Authorities for a period of over six months.

Additionally I will overview the revocation behavior of the most common browsers, identifying the gaps as they exist in those implementations.

And finally I will provide a set of recommendations that I believe if followed can address the current gaps which would move us to a world where revocation checking is an effective means of protecting relying parties from known bad actors and miss-issuance.

Using ECC keys in X509 certificates

Leave a reply

Recently the CAB Forum published a document called the Baseline Requirements for the Issuance and Management of Publicly Trusted Certificates.

This document was authored by both browsers and public CAs and is used by the browser vendors to mandate what minimum technical requirements need to be met for inclusion into their “Root Programs”.

One of the changes specified in this document is that subscriber certificates (aka SSL certificates) containing RSA keys must have a bit length of 2048. This is a change for a lot of CAs (GlobalSign had made this change some time ago) one that has implications to server operators.

Just take a look at the Crypto Plus Plus Benchmarks to see how much more expensive 2048 bit RSA. For most users this additional computational cost won’t be an issue but in some cases customers may need to increase the computing power they allocate for SSL establishment.

But what alternatives do you have? Well there is one, certificates with ECC keys; using these have the potential to significantly decrease the computational costs for SSL negotiations (even over your old 1024bit RSA certificate) but they come at a significant penalty – compatibility.

ECC was not supported in Windows until VISTA which was released in 2009, this basically means 100% of the XP clients out there (around 29% of the browsers on the internet as of July 2012) would be unable to establish a session with your website if you switched exclusively to ECC.

This is important for more than just Internet Explorer users since even Chrome and Safari use CryptoAPI for certificate validation when on Windows.

This would mean these users would see something like this:

 

That is pretty scary, so how long until we can use this more broadly? It’s hard to say there is a good article titled “The developers guide to browser adoption rates” that sheds some light, that and the historic gs.statcounter.com results. Based on these unless there is a sudden change (which is possible these machines are getting pretty old) I would assume that we have around 4-5 years of XP out there yet.

Hope this helps,

Ryan

Using SHA2 based signatures in X509 certificates

6 Replies

It’s been an exciting decade for cryptography; as a result we see smaller key sizes and weaker algorithms getting deprecated.

One driver of such things is the U.S. Federal Government, specifically NIST.

One example of this would be NIST Special Publication 800-131A which disallows the use of SHA1 after December 2013. What this means is if you are in the U.S. Federal Government or you work with them you may have to revise your technology strategy to use SHA2 in its place.

But what if you don’t have any policy mandate forcing you to do this switch? Well it’s a good idea but it has consequences too, namely compatibility.

You see SHA2 was published in 2001 so anything produced before then will not support it. The most notable example is Windows XP which as of July 2012 has about 29% presence on the Internet.

This is important for more than just Internet Explorer users since even Chrome and Safari use CryptoAPI for certificate validation when on Windows.

The good news is that XP SP3 which was released in 2008 added support for this new suite of hash algorithms, that begs the question how many of those XP machines have XP SP3?

Unfortunately I don’t have any public references that can answer this question but let’s that 85% of all XP machines on the Internet have gotten this update (I have good confidence in this number) that means that 15% of those 29% would not be able to connect to your server over SSL if you used SHA2.

This would mean these users would see something like this:

 

 

That is pretty scary, so how long until we can use this more broadly? It’s hard to say there is a good article titled “The developers guide to browser adoption rates” that sheds some light, that and the historic gs.statcounter.com results. Based on these unless there is a sudden change (which is possible these machines are getting pretty old) I would assume that we have around 4-5 years of XP out there yet.

Hope this helps,

Ryan

How to get your own OID arc

Leave a reply

X509 uses Object Identifiers (OIDs) to uniquely identify things, for example one assigns a OID to their Certificate Policy Statements (CPS) so that it is possible to programmatically detect if a certificate meets a specific policy.

OIDs are managed as a namespace, this prevents “collision”. As such one needs to request an OID be assigned to them.

The “arc” part comes when you get your OID, you can assign any number you want at the end of your OID. For example, one might be assigned 1.1.1.1 and decide to “break” it up into chunks as follows:

  1. 1.1.1.1.2 – Documents
  2. 1.1.1.1.3 – Certificate Extensions
  3. 1.1.1.1.4 – Resource Identifiers

Underneath each of these you would assign unique numbers by appending a new number, for example 1.1.1.1.2.1 might be your CAs Certificate Practice Statement (CPS).

So how do you get one of these OIDs then? That’s easy it’s Internet Assigned Numbers Authority (IANA) who assigns these, they call them Private Enterprise Numbers. Getting one is easy enough just fill out a web application form. To do that you will only need 7 pieces of information, these include:

  1. Organization Name
  2. Organization Address
  3. Organization Phone
  4. Contact Name
  5. Contact Address
  6. Contact Phone
  7. Contact Email

Remember the idea is that the information you provide here will be used for people to reach you if they want to ask questions about these things you have uniquely identified so choose the values wisely.

It can take up to 60 days to get one of these (although usually the application is processed in about one week).

Once you got the object identifier, you should register the code on the site www.oid-info.com and/or www.alvestrand.no in this way will be easily accessible by those who are seeking information about the owner of object identifier.

Hope this helps.

Ryan

MSRC 2718704 and Nested EKU enforcement

Leave a reply

There are a number of technical constraints a Certificate Authority can put into place on a subordinate Certificate Authority; the general concept is referred to as Qualified Subordination.

One of the most important ways to constrain a certificate is through by restricting what it can be good for.

The foundation for such a constraint is provided by PKIX in the Extended Key Usage extension (RFC 5280), this extension can be put into a certificate to restrict what it is trusted for – for example a certificate might be OK for SSL Server Authentication but not for S/MIME.

The problem is the RFC provides no practical guidance on how to act when this certificate is encountered in a CA certificate, all it says is:

In general, this extension will appear only in end entity certificates.

One can interpret this to mean that its semantics are the same in issuer or subscriber certificates, this makes sense but isn’t very useful as a CA is not very likely to ever perform “application tasks” like S/MIME or SSL Server authentication with its signing key, so why would you put it in a CA certificate?

Also if you look back at the history this extension was really one of the first that was introduced, it came into existence in a time where PKIs were only one level deep – the absence of guidance on how to handle this could easily be seen as an omission.

Microsoft saw it this way and decided to have their implementation treat this extension as a constraint, in other words if no EKU is present in the chain then the chain is considered good for all usages. But once a single EKU is added into the path nothing bellow it can be considered good for a non-listed EKU.

In Windows applications validate certificates using the CertGetCertificateChain API takes a number of control parameters via the PCERT_CHAIN_PARA structure, one can specify what EKUs they want to make sure a certificate is good for via the RequestedUsage parameter.

This logic (frankly almost all of the certificate validation) is all wrapped into this one call.

So what does this have to do with MSRC 2718704? Well it has reduced the risk of this mess up in a meaningful way I thought I would explain but before I do let me explain that I am not trying to downplay the significance of this issue I am just trying to clarify where the risks are.

As we know now the “licensing solution” deployed for terminal services has put a signing CA that is trusted for Code Signing in ever enterprise that uses the product.   But how is it restricted to just Code Signing, that’s really what this post is about.

Let’s look at the EKUs included in the offending “MS” certificate, in that chain we see:

  • Microsoft Root Authority
    • No EKUs
  • Microsoft Enforced Licensing Intermediate PCA
    • EKUs = Code Signing, Key Pack Licenses, License Server Verification
    • Effective EKUs = Code Signing, Key Pack Licenses, License Server Verification
  • Microsoft Enforced Licensing Certificate Authority CA
    • EKUs = Code Signing, License Server Verification
    • Effective EKUs = Code Signing, License Server Verification
  • Microsoft LSRA PA
    • EKUs = None
    • Effective EKUs = Code Signing, License Server Verification
  • MS
    • EKUs = None
    • Effective EKUs = Code Signing, License Server Verification

You will notice that the “Microsoft LSRA PA” certificate lists no EKUs but the Effective EKUs are listed as “Code Signing” and “License Server Verification”, this is because of the Nested EKU behavior I describe above.

The same thing happens in the end “MS” certificate; even though it has no EKUs listed I can only be used to validate licenses and sign-code because that’s all it’s issuers are entitled to bestow onto its subordinates.

OK so what does all of this mean to you and me? It basically means as long as the application is written using CryptoAPI in the intended way (and all do that I am aware of in this context) those CAs out there cannot be used to issue SSL certificates (or any other usages not listed) that would be “valid”, they can of course sign code as Microsoft which is a larger issue in my book.

Anyway over the years I have proposed in IETF that this same behavior be adopted, it was always rejected as an evil Microsoft conspiracy (I was at Microsoft at the time) it of course was nothing of the sort but in the end I gave up. Recently I have started trying to convince the browsers directly to implement this same behavior as I feel it is beneficial, for example here is a NSS bug tracking the same request, if implemented that would take care of Chrome and Firefox, that still leaves Safari and Opera but it’s a step in the right direction.

 

Additional Resources

http://lists.randombit.net/pipermail/cryptography/2012-June/002966.html

Getting beyond 1% — How do we increase the use of SSL?

2 Replies

Today about 1% of the traffic on the Internet is protected with SSL (according to Sandyvine), there are a few key issues keeping this number so small and I thought I would put together a quick post on what I think those issues are.

 

Interoperability

For over a decade we have been working towards migrating to IPv6, despite that we have made little progress, in-fact they say that at the end of 2012 we will run out of IPv4 addresses.

As far as I know not one of the top 10 CAs support IPv6 yet (yes, not even GlobalSign though were working on it). This means it is impossible to host a pure IPv6 SSL solution today (because of the need for revocation data).

This is also interesting because today many sites are hosted on virutal hosting solutions that share the same IP address — this is primarily because IP addresses are a scarce resource, it has the side effect of making it hard (sometimes impossible) to deploy SSL on these hosts.

In 2003 an extension to TLS was proposed to address this problem it’s called Server Name Indication (SNI – now defined RFC 6066).

Today the server support for this extension is quite good but the same can not be said for client support (due to the lingering XP population and influx of mobile devices).

In my opinion this is the #1 issuing holding back the adoption of SSL everywhere.

 

Complexity

It is amazing to me but very little has changed in the CA industry since it’s birth in the mid 90s, certificates are still requested and managed in essentially the same way – it’s a shame, it’s wasteful.

One of the reasons I joined GlobalSign is they have been trying to address this issue by investing in both clients and APIs (check out OneClick SSL and CloudSSL) — with that said that there is still a lot more that can be done in this area.

Then there is the problem of managing and deploying SSL, the SSL Pulse data shows us it’s hard to get SSL configured right; we are getting better tools for this but again there is still a ton of room for improvement.

 

Performance

There has been a bunch of work done in this area over the years; the “solutions” relating to  performance of SSL seem to be broken up into:

  1. Protocol improvements (SPDY, FalseStart, OCSP Stapling, etc.)
  2. Using different cryptography to make it faster (Smaller keys, DSA, ECDSA, etc.)
  3. Using accelerator products (F5 BigIP, NetScaller, SSL Accelerators, etc.)

I won’t spend much time on protocol improvements as I think it gets a ton of coverage from the likes of Google who have made several proposals in this area over the last few years. I do have concerns with these protocol changes introducing interoperability issues, but I can’t argue with the performance benefits they offer.

You will notice I also included OCSP Stapling in this group, I think this is a great way to improve revocation checking but it’s not about security, it’s about performance and reliability – you should just use this today, it’s safe and very likely supported by your servers already.

The use of different cryptography is an interesting one, however again the issue of compatibility rears its ugly head. Though every implementation of an algorithm will perform differently the Crypto++ benchmarks are a nice way to get high level understanding of an algorithms performance characteristics.

There is a lot of data in there, not all of it related to SSL but one thing definitely is the performance characteristics of RSA vs DSA:

Operation Milliseconds/Operation Megacycles/Operation
RSA 1024 Signature 1.48 2.71
RSA 1024 Verification 0.07 0.13
DSA 1024 Signature 0.45 0.83
DSA 1024 Verification 0.52 0.94

 

You will notice that with RSA it is more expensive to sign than it is to verify, you will also notice that with DSA the opposite is true (it is also faster in this sampling).

Since in the case of SSL it is the server doing the signature and the client doing the verify this is an important fact, it means a server using a DSA certificate will spend less time doing crypto and more time doing other stuff like serving content.

On the surface this sounds great, there are of course problems with this though – for one because of the work researchers have done to “break” RSA over the last few years the browsers are moving CAs to not issue 1024bit RSA keys (by 2013) an effort which CAs have also applied to DSA.

Another not-so trivial factor is that Microsoft only supports DSA keys up to 1024 bits in length which means the larger DSA keys are not viable on these platforms.

So what of the new ciphers like AES and ECDH-ECDSA? This will represent a very large performance boon for web server operators but they too like SNI are not supported by legacy browsers.

What this means for you is for the next few years we have to make do with the “legacy cipher suites” as a means to facilitate TLS sessions.

Miscellaneous

Not everything fits neatly into the above taxonomy, here are a few common topics that don’t:

  1. Increased cost of operation
  2. Inability to do “legitimate” packet inspection

Increased cost of operation can be summerized needing more servers for the same load due to the increased SSL computational costs.

Inability to do “legitimate” packet inspection can be summarized as limiting he practical value of existing security investments of technologies like Intrusion Detection and Network Optimization since once the traffic is encrypted they become totally innefective. To work around this issue networks need to be designed with encryption and these technologies in mind.

 

Summary

I personally think the biggest barriers is ineroperability, the biggest part of this being the lingering XPs installations; the silver lining being the last few years XP has lost market share at about 10% per year, at the current rate we are about three years from these issues being “resolved”.

In the mean time there is a lot the industry can do on the topic of complexity, I will write more on this topic another time.

Attending workshop on “Improving the Availability of Revocation Information”

Leave a reply

At the most recent CA/Browser Forum folks from DigiCert and I both made presentations on what’s needed to improve the current state of revocation in X.509.

There were really two different themes in these presentations:

  1. We can better use the technologies we have today.
  2. We can make “tweaks” to the technologies we have today to improve the situation.

It was not really possible to go into any details about these proposals given the time slots allocated were more presentation oriented and since the DigiCert guys had already engaged with Maximiliano Palla of NYU Polytechnic University (the founder of the OpenCA project) they agreed to work with him to arrange this workshop.

The session is April 16th (I leave tomorrow) and I am looking forward to the chance to talk about this topic, my goals for the session are we get to agreements on:

  1. Authoring a whitepaper on OCSP responder best practices.
  2. Authoring a whitepaper on revocation client best practices.
  3. Agreeing on an approach to “opt-in” hard revocation checking.
  4. Agreeing on a path forward to resolve the many outstanding Firefox revocation issues.
  5. Funding Nginx to add support for OCSP stapling this year.

There are lots of other potentially interesting topics I am sure will come up:

  1. Getting Apache’s OCSP stapling enabled by default.
  2. Short-lived certificates, their potential and challenges.
  3. Defining a new transport for OCSP via DNS.
  4. Defining a new query-less OCSP like protocol.
  5. CRLsets and their place in the browser ecosystem.

Should be an interesting day for sure.

OCSP Responder Performance Needs Improvement

2 Replies

Recently I set up a PingDom monitor to track the overall performance of the various OCSP responders out there, PingDom is limited to doing GETs and cannot parse the responses from the responders but it’s a fair mechanism to look at response time.

These tests run from a number of different global locations and are averaged together, the locations change but the same locations are used for each set of tests so again this seems fair.

I decided to use the Google logo as my control test, as it is about the same size as a larger OCSP response, after about a month of monitoring this is what I saw:

Test Avg. Response time
Google Logo (3972 bytes)

44 ms
GoDaddy OCSP

186 ms
GlobalSign OCSP

228 ms
Digicert OCSP

266 ms
Comodo OCSP

268 ms
TrustCenter OCSP

273 ms
TrustWave OCSP

315 ms
Startcom OCSP

364 ms
Entrust OCSP

371 ms
Geotrust OCSP

432 ms
VeriSign OCSP

510 ms
CyberTrust OCSP

604 ms
Certum OCSP

776 ms

As you can see the fastest responder is over four times slower than the Google logo, far from acceptable.

When looking at the individual responses and their responses this is what I saw:

  • Very few responders are using CDNs, AnyCast or other techniques to globally distribute responses.
  • Only a handful of responders have multiple DNS entries for failover scenarios.
  • Quite a few responders are not following the HTTP caching header requirements in RFC 5019.
  • Most responders are not sending CA signed responses which reduce the response size significantly (down to 471 bytes), in my opinion a OCSP responder should do this for all pre-produced responses.
  • Some responders are returning Unknown for out of scope responses, this really isn’t safe for unauthenticated requests as it exposes the responder to resource consumption denial of service for against the signing keys.
  • Response freshness ranges from 6 hours to 14 days, I am quite sure the six hour responses are failing for a very large % of the internet community due to time skew; 4 days appear to be optimum.

These are all fairly easy things to address and I believe it’s reasonable for responders to get down to response times that are consistent with the control test above.