Category Archives: Thoughts

Browser Revocation Behavior Needs Improvement

6 Replies

Today the best behaving client for revocation behavior is that of Windows, in the case of browsers that means IE and Chrome.

With that said it has a very fundamental problem, if it reaches a CA’s OCSP responder and it provides an authoritative “that’s not mine” (aka Unknown) clients built on this platform treat the certificate as good.

You got that right; it treats a certificate that is clearly invalid as good! This unfortunately is a common behavior that all the browsers implement today.

The other browsers are even worse, Firefox for example:

  1. Do not  maintain a cache across sessions – This is akin of your browser downloading the same image every time you opened a new browser session instead of relying on a cached copy.
  2. Does OCSP requests over POST vs. GET – This prevents OCSP responders from practically utilizing CDN technology or cost-effectively doing geographic distribution of responders
  3. Do not support OCSP stapling – IE has supported this since 2008, Firefox even paid OpenSSL to add support around the same time but they have yet to get support in themselves.

These each seem like fairly small items but when you look at all these issues as a whole they significantly contribute the reality we face today – Revocation Checking isn’t working.

There are other problems as well, for example:

In some cases browsers do support GET as a means to do a OCSP request but if they receive a “stale” or “expired” response from an intermediary cache (such as a corporate proxy server) they do not retry the request bypassing the proxy.

All browsers today do synchronous revocation checking, imagine if your browser only downloaded one image at a time in series; that’s in-essence what the browsers are doing today.

These and other client behaviors contribute to reliability and performance problems that are preventing Hard Revocation Checking from being deployed. These issues need to be addressed and the browser vendors need to start publishing metrics on what the failure rates are as well as under what conditions they fail so that any remaining issues on the responder side can be resolved.

 

How to do OCSP requests using OpenSSL and CURL

10 Replies

 

It pretty easy, the OpenSSL and CURL manuals make it fairly easy but I thought I would put it all here in a single post for you.

First in these examples I used the certificates from the http://www.globalsign.com site, I saved the www certificate to globalsignssl.crt and its issuer to globalsignssl.crt.

Next you will find a series of commands used to generate both POSTs and GETs for OCSP:

1. Create a OCSP request to work with, this also will produce a POST to the OCSP responder

openssl ocsp -noverify -no_nonce -respout ocspglobalsignca.resp -reqout ocspglobalsignca.req -issuer globalsigng2.cer -cert globalsign.com.cer -url "http://ocsp2.globalsign.com/gsextendvalg2" -header "HOST" "ocsp2.globalsign.com" -text

2. Base64 encode the DER encoded OCSP request

openssl enc -in ocspglobalsignca.req -out ocspglobalsignca.req.b64 -a

3. URL Encode the Base64 blob after removing any line breaks (see: http://meyerweb.com/eric/tools/dencoder/ for a decoder)

4. Copy the Base64 into the URL you will use in your GET

http://ocsp2.globalsign.com/gsextendvalg2/{URL encoded Base64 Here}

5. Do your GET:

curl --verbose --url http://ocsp2.globalsign.com/gsextendvalg2/MFMwUTBPME0wSzAJBgUrDgMCGgUABBSgcg6ganxiAlTyqPWd0nuk87cvpAQUsLBK%2FRx1KPgcYaoT9vrBkD1rFqMCEhEhD0Xjo%2FV7lgq3ziGoWG69rA%3D%3D

 

If you like you can also re-play the request that was generated with OpenSSL as a POST:

curl --verbose --data-binary  @ocspglobalsignca.req -H "Content-Type:application/ocsp-request" --url http://ocsp2.globalsign.com/gsextendvalg2

Hard revocation checking and why it’s not here yet.

Leave a reply

If you follow discussions around x.509 and SSL you have likely heard that “Revocation Checking is Broken”, you might even hear it will never work therefore we should start over with a technology that isn’t dependent on this concept.

There are some merits to these arguments but I don’t agree with the conclusion, I thought I would summarize what the problems are in this post.

Fundamentally the largest problem is that, as-deployed, all x.509 revocation technologies introduce a communication with a third-party (the Certificate Authority).

This isn’t necessarily a deal breaker but it does have consequences, for example in the case of SSL:

  1. It can slow down the user’s experience.
  2. It introduces a new point of failure in a transaction.

These issues can be mitigated through intelligent deployments and engineering but unfortunately this really has not happened, as a result Browsers have implemented what is called “Soft-fail revocation checking”.

With soft-fail revocation checking browsers ignore all conditions other than an authoritative “revoked” message, in the case of OCSP that means if they reach the responder and it says “I don’t know the status” or if it fails to reach the responder it assumes it is “good”.

This behavior is of course fundamentally flawed, the Browsers say they have no choice (I disagree with this conclusion but that’s a topic for another post) other than to behave this way, but why?

The rational is as follows:

  1. Revocation repositories are not reliable.
  2. Revocation repositories are slow.
  3. Revocation repositories are not always available (captive portals).
  4. Revocation messages are too large to be returned in time.
  5. There are too many revocation messages to be returned in time.

These are all legitimate concerns, ones that are unfortunately as true today as they were almost a decade ago.

They are not however insurmountable and I think it’s time we as an industry did something about it.

SSL/TLS Deployment Best Practices

1 Reply

SSL/TLS seems simple, you go to a CA to prove who you are they give you a credential, you install it on your server, turn on SSL and then you are done.

Unfortunately there is more to it than that, I recently had an opportunity to contribute to a Best Practices Guide (PDF)  that aims to provide clear and concise intructions to help administrators understand how to people deploy it securely.

The intention is to work on an advanced version of this document in the future that covers more details and advanced topics as well (think OCSP Stapling, SPDY, etc).

I hope you find it useful.

Leaving Microsoft, My Goodbye Letter

Leave a reply

Here is my goodbye letter to all of the amazing people I worked with over the last decade:

It was December 2001 when I came back to Microsoft. I joined the team chartered to build security technologies into Windows; I could think of nowhere else I wanted to be. After all, what other technology company in the world had the opportunity to positively impact the security of so many?

In my time here I have had the honor of working with some of the best and brightest our industry has to offer, working on some of the largest and most ambitious software engineering challenges in the world.

I have had the opportunity to work on platforms for cryptography, public key infrastructure, smart cards, biometrics, network authentication and policy, network isolation, cloud authentication, document signing, code signing, secure boot, volume encryption, enthusiast user experience, helped secure the advertising platform and so much more.

All the while I had the honor (and responsibility) of representing Microsoft in standards forums, working closely with industry partners and leaders to deliver the technology that has laid the groundwork for the consumerization of IT we are experiencing today.

My time here has taught me more than I ever thought it would; as much as the experiences themselves made me better, my greatest lessons came from you. Sometimes these lessons were a result of the folks I worked with respectfully helping me grow, but in many cases they came from simply watching how easy you all make the stuff we do look.

For these lessons I want to thank you.

Ten years later, a new set of challenges are emerging; Certificate Authorities are being forced to re-evaluate how they do business as a result of Advanced Persistent Threats and emerging technologies changing the way trust is communicated on the Internet. These challenges, of course, also represent an opportunity.

As such, I have accepted a position with GlobalSign as their Chief Technology Officer, where I have an opportunity to re-think what it means to be a trusted third-party. My last day will be January 20th.

Please keep up the good work and don’t be a stranger,

– Ryan Hurst
rmh (at) unmitigatedrisk.com
http://unmitigatedrisk.com/
@rmhrisk on Twitter

The Contrition of a Security Practitioner

Leave a reply

The Encarta World Dictionary says that Contrition is “the deep and genuine feelings of guilt and remorse”. Having been involved in information security for 20 years, now, I think I can sincerely say that many security practitioners would say this is how they feel about the early days of their careers.

Why, you ask? Well, in my case, I started my career doing work for large financial institutions and governments. Back then these sorts of customers often had a “security at any price” mantra. While one would need to assess the risk of a system to secure it, these sorts of customers would also plan to mitigate as many of the identified risks as possible.

For these customers this was not necessarily a bad approach, but that had more to do with what was at risk than it did with the approach being a sound one.

Today the world is a different place; security is something that even the smallest businesses need to consider. This change did not occur overnight. It was gradual and I guess this is where the contrition comes in.

You see many applied the same approaches that worked with those financial and government customers with Fortune 500 and later Fortune 1000 companies. While in some cases this was appropriate, in most cases it was not.

The modern security practitioner needs to take a more holistic look at the business and platform they are servicing to understand its schedule and technological needs along with what the immediate business risks are.

Beyond that, the breadth of the role has changed and expanded. Security practitioners are now commonly responsible for Compliance, Reliability and Privacy, as well.

This puts the security practitioner in an interesting position; with this more complete view they can now help improve:

  • time to market, by recommending solutions that are risk-appropriate for the business;
  • engineering efficiencies, by identifying areas where work is being done inefficiently;
  • systems and processes, by identifying gaps and potential failure points that can negatively impact the business;
  • how teams allocate their scarce resources, by identifying opportunities where they’ll do the most good, based on risk vs. return.

This represents a significant shift from a decade or two ago, and requires the security practitioner to no longer simply be an outside expert but become part of the development team they support.

This is one of the reasons the Security Champion model is used in many teams here at Microsoft. While it has its challenges, as a member of the feature team a champion has the opportunity to have and share these more holistic insights as I called out above.

A good example of this is the application of cryptography to solve business problems. Cryptography is a powerful tool, but it’s often misapplied, introducing fragility and operational overhead that can be avoided; I think this is best summed up by this quotation:

If you think cryptography will solve your problem, then you don’t understand cryptography… and you don’t understand your problem. — Bruce Schneier

So, my ask of you as an engineering manager is to have a formal Security Assurance program for your team and as a software engineer incorporate your security specialists early and often. They either have direct experience in the areas I discussed here, or are in the position to bring those resources to your aid … to not only help you secure your offerings, but to do so in record time, as well.

What is a wildcard certificate and why are they a bad idea?

4 Replies

Wildcard certificates are SSL/TLS server certificates that unlike their traditional counterparts bind a entire domain (or sub-domain) to a single private key, for information on the kind of wildcards one can specify see: http://support.microsoft.com/kb/258858.

Why would someone want to have a certificate like this? Well in my experience the decision is most often made on cost factors (acquisition, management, and politics), in other words I would rather buy onecertificate for my entire server farm instead of one for each server.

What makes the use of these certificates a bad idea? Well there are several reasons:

First, SSL/TLS typically provides two key properties; authentication of the server and confidentiality of the session; the core value of that pair is the authentication of the server as you should not even consider submitting data if you don’t know who its going to and if you never submit data you don’t need to worry about if the session is encrypted (most of the time).

Lets explore why we care about “who” were talking to and why that need to specific, certification authorities only issue certificates to entities that agree to something commonly referred to as a subscriber agreement; this agreement obliges the subscriber to have certain practices, the most basic of which might be not to publish the associated private key on the web or to not host malicious content.

With a wildcard certificate you may or may not know if the site content your experiencing agreed to such an agreement, more over you have a pretty high probability that the private key associatedwith the certificate exists in multiple locations, this also increases the likely hood that the private key is in software and not hardware making it a practical possibility a remote exploit could expose the private key to an attacker.

Then there is the question of who your talking to, many sites use sub-domains (for example WordPress), this becoming more and more common with the exhaustion of easy to remember domains and new community sites that what remember-able URLs for their members, each of these “subs-sites” typically have control over their own content and knowing who their hosting provider is doesn’t tell you anything about them in particular.

Now I am not suggesting that having a certificate tells you that the content being served from that host is somehow more trustworthy but knowing who you are talking to went to the trouble to prove who they are to you is useful when making a trust decision.

Secondly there is the practical issue of key management, as I mentioned earlier you know that the key has (very likely) been shared amongst multiple hosts, and keys that have been spread out like the dogs breakfast are much less trustworthy than ones that have never been shared.

If these things are so bad why did they get developed? Well there are a few reasons, certainly cost was one of the but I actually believe it was done in the hope to enable intermediary SSL/TLS accelerators too to service multiple sites; the thing is that these devices have always been able to handle different certificates for each of the hosts they secure so this would have just been a excuse.

In my opinion all browsers should have a setting that allows users to disable the wildcard behavior, in-fact I would go so far to say that this should be the default.

There is another similar case to the wildcard certificate, it is possible to bind multiple identities to a single key pair, one can put in multiple Subject Alternate Names, in other words I can create a certificatethat binds 100 host names into a single certificate; this still has many of the problems of a wildcard certificate and I would argue that this case should also be covered by any setting that disabled ambiguously bound certificates.

Alun Jones has a good blog post from a while ago on this topic that is worth a read too.

ASKING THE DRUNK IF THEY ARE DRUNK

Leave a reply

For a over decade there has been a slow move towards building networks where only authenticated users can get on (wireless networks are a great example of this), this later moved towards building networks where onlyauthenticated users on managed machines get on, the most recent change to this trend has been to add checks that also require these machines meet a base-line configuration that gives the network administrators some idea of what kind of risks they are exposed to by letting these machines on their networks.

This all makes sense, after all machines that do not have up-to-date antivirus or the latest patches certainly represent more risk to the network than those that do.  A great example of this is actually SQL Slammer, even today five years after the patch for this vulnerability it is still negatively effecting customer environments.

Analysts have given solutions in this space the label of Network Admissions Control (NAC), these systems rely on two basic models one where the behavior of the host is externally monitored and its access is limited if it behaviors out of norm with the networks policy and another where the host makes claims about its configuration that is then evaluated to decide of the host is conformant with the networks policy to see if access should be limited.

Both of these models are examples of what I call “asking the drunk if he is drunk”,  I say this because in both cases the client can control if it displays a behavior (I used to work with a security consultant who would always say “give me your rules and I will comply with them”, this is a example of just that – warning pdf link) or produces a claim that will result in access being given or restricted. The core difference between the two approaches is how rich is the information that is available to make policy decisions on.

The problem with this is if we are to deploy solutions like this we must also accept that it is possible for malware (like root kits or other malicious host software) to change the behavior of the host so that it isn’t “caught” by these checks.

If thats really the case do these systems still have value? I would argue they do, you see they give systems administrators get something they have never really had before, insight into their networks risk profile (how many people on my network do not have this patch, are not running antivirus or have out of date signatures, etc.).

There are other values too, in general users actually “want to do the right thing™” but they don’t necessarily know what that means and these systems help them do just that, in addition these systems often implement concepts of “automatic remediation” so that you can remove the obligation of the user to do anything and instead you just fix it for the user without their interaction.

These reasons underscore why even in computing it’s important to “pull the drunk over and ask him to walk the line”, but does this mean we should accept the status quo? I would say no, although it will never be possible for a running system to evaluate its own state in without potentially being fooled there are lots of things we can do to make the host itself more trustworthy.

As a example many of the technologies in VISTA do just that (and I thinkSymantec would agree), some of the technologies in VISTA that help here today include:

  • Bitlocker – Protects the host from offline attacks of trusted software components and cryptographic keys.
  • Secure Startup – Increases the trustworthiness of the OS by checking to see that core components are authentic as part of the startup sequence.
  • Code Integrity – Increases the trustworthiness of the running state of the OS by checking to see if they are authentic before being loaded.
  • UAC – Reduces the negative impact that can be caused by careless users and/or malware by giving these processes a restricted token.
  • ASLR – Makes it more difficult for malware to attack running code by randomizing where code is running in memory.
  • DEP – Makes it more difficult for malicious code to get and keep running.

This represents just the beginning through, future versions of these conditional network access solutions will also leverage hardware that runs before the operating system (TPM) to verify that the components that implement the above are not tampered with before the operating system even is invoked.

Later systems will even be able to use virtual machines to add even more protection from these sorts of attacks, again that’s not to say that when we get here we will have made these systems fool proof; it’s just not possible(my friend Cem always has great analogies, one of my favorites is “Security is often a exercise of re-arranging deck chairs on a sinking ship” this problem is a example of just that) but that doesn’t mean there is not value in raising the bar and I think the industry is well on its way to do just that.

As a side note, we have deployed the Microsoft solution in this space (Network Access Protection) to over 75,000 hosts over the last few months pretty cool if you ask me.