of TLS/SSL Server Identity Checking

February 1st, 2011

[ Update (23-Apr-2011): This spec was published as RFC6125 on 30-Mar-2011. See also this more recent post. ]

Aside from HSTS, which I’ve written about here earlier, I’ve also been working on a specification for “TLS/SSL Server Identity Checking” along with Peter Saint-Andre.

The basic summary is: you have a DNS domain name identifying some application service (aka “a server”) you wish to connect to over TLS/SSL, e.g. “www.example.org”, and once you do so, how do you really know (and check) that the returned PKIX Certificate contains an identifier(s) that maps to the name of the application service you intended to interact with?

This turns out to be a fairly complex endeavor, and up to the present here, various protocol specs have either specified it on their own, or have referenced another spec that has addressed the problem. One such referenced spec is RFC2830, “Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security“, which I co-authored. So anyway, I got involved a few years back in trying to concoct a dedicated specification for how to do TLS/SSL server identity checking in an application protocol neutral fashion. Eventually, Peter Saint-Andre and I signed up to buckle down and make the spec a reality. Much of this work occurred during 2010.

The resulting internet-draft, draft-saintandre-tls-server-id-check, was approved on 20-Jan-2011 as a Proposed Standard RFC, and will be published as such in the next couple of months. It has this fairly precise but unwieldy title:

Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)

In the spec (which has been referred to as “-tls-server-id-check” in various email discussion threads (e.g. see the certid@ietf.org list), we provide an appendix of extracts from various current RFCs that specify performing such a check. The hope is that, going forward, emerging specifications can simply reference (i.e. “re-use”), and profile if necessary, the -tls-server-id-check spec. In fact, there’s presently four Internet-Drafts in the RFC-Editor’s work queue that do just that.

=JeffH sez check it out :)

Firesheep and HSTS (HTTP Strict Transport Security)

October 29th, 2010

Firesheep, released earlier this week, is a Firefox add-on that enables one to easily capture HTTP application session cookies from other users communications with specific popular sites. The problem it exploits is that many sites protect the initial reusable shared password-based authentication with TLS/SSL, but then revert further communication to unsecured HTTP. This exposes any application session cookies employed by the site, and returned by users’ browsers to the site on every request, to capture and replay by an attacker. This enables one to hang out on a local network, your favorite coffee shop for instance, and hijack others’ interactions with various social networking sites and retailers, for example.

This particular class of typical website vulnerability has been known for ages, as well as techniques for addressing it. For example, websites can simply offer their entire site over TLS/SSL (i.e. via “HTTPS“), as PayPal does. Some sites do so, but for whatever reason still revert users communications to unsecured HTTP by default, or some portion of their communications remain unsecured. However, if one can configure one’s browser to only securely interact with some given site (i.e. domain), and if the site supports this, then Problem Largely Solved. See, for example, Collin Jackson and Adam Barth‘s paper, ForceHTTPS: Protecting High-Security Web Sites from Network Attacks, for a description of this class of vulnerabilities, attacks, and remediation approaches.

I’ve been working with Collin and Adam on standardizing ForceHTTPS — their paper was the inspiration for the HTTP Strict Transport Security (HSTS) work and the present Internet-Draft specification thereof, and thus the HSTS implementations presently available in Firefox 3.x (via the Force-TLS and NoScript plugins), natively in Firefox 4 beta 6 and later, and natively in Chrome 4 and later. There’s also the HTTPS-Everywhere extension from the EFF that comes pre-loaded with a list of sites to use only via HTTPS, and is configurable such that one can add more (unfortunately it doesn’t support HSTS apparently)..

Now, HSTS is a website security policy that in typical cases, sites will explicitly signal to browsers (via an HTTP request header field), as PayPal presently does. However, this week, Sid Stamm, who authored the Firefox v3 HSTS add-on (Force-TLS) and native implementation, conzed-up a new Firefox v4 add-on, STS UI (Strict Transport Security User Interface), that allows one to configure one’s browser to regard given sites as HSTS sites, even if they don’t signal it. This also addresses the Bootstrap MITM Vulnerability noted in the HSTS draft spec.

Note that Chrome features “Preloaded HSTS sites”, and that NoScript (FF v3 & v4), HTTPS-Everywhere (FFv3), and Force-TLS (FFv3) all facilitate user configuration of HTTPS-only sites.

We’ll be working in the new IETF WebSec working group to finish the HSTS draft spec and get it published as an RFC, hopefully before too much of 2011 is gone. I’ll try to keep you all updated on that.

In the meantime, =JeffH sez be careful with your web logins :)

updated 31-Oct-2010: Added NoScript and HTTPS-Everywhere. Apologies to Giorgio and the EFF for not including them straight away.

HSTS implemented in Firefox 4 and Chrome

October 28th, 2010

In terms of HSTS implementations, it’s now been implemented in the mainline Firefox code by Sid Stamm, and is supported in the Firefox 4 beta 6 and later. Note that HSTS is already a feature in Google Chrome as of version 4.

=JeffH sez check it out 😉

HTTP Strict Transport Security and the IETF WebSec Working Group

October 28th, 2010

The HTTP Strict Transport Security (HSTS) spec is now an IETF Internet-Draft, and available here (for now; more about that below): http://tools.ietf.org/html/draft-hodges-strict-transport-sec

We had a successful “HASMAT” (for “HTTP Application Security Minus Authentication & Transport”) BoF at IETF-78 Maastricht last July, which has resulted in the formation of a new IETF Working Group: WebSec. Plus, the HSTS spec, and two others, were adopted as working group items.


So this means I need to get off my butt and edit the HSTS spec such that it’s a proper “working group (internet-)draft” and get it published….

The Need for a Coherent Web Security Policy Framework

October 28th, 2010

Back in May (apologies for latency, we’ve had a busy summer/fall), Andy Steingruebl and I presented our paper, “The Need for a Coherent Web Security Policy Framework” (slides), at the Web 2.0 Security and Privacy 2010 Workshop. It seemed to be relatively well received (the abstract is below). There were a number of interesting papers at the workshop, browsing the workshop pages is encouraged :)

Since then, we’ve been waving our paper around and pursuing the action items outlined therein with some modest success, which I’ll outline in subsequent posts.

=JeffH sez check it out…


Web-based malware and attacks are proliferating rapidly on the Internet. New web security mechanisms are also rapidly growing in number, although in an incoherent fashion. In this position paper, we give a brief overview of the ravaged web security landscape, and the various seemingly piece-wise approaches being taken to mitigate the threats. We then propose that with some cooperation, we can likely architect approaches that are more easily wielded and provide extensibility for the future. We provide thoughts on where and how to begin coordinating the work.

New rev of Strict Transport Security (STS) Specification

December 23rd, 2009

Details are over here..


=JeffH sez check it out :)

Browser Security Handbook

December 14th, 2009

The Browser Security Handbook, brought to us by Michal Zalewski (of Google) is a quite useful document (droll understatement). It documents various security facets of the leading web browsers and provides succinct tabular comparisons of behaviors. It is available here..

Browser Security Handbook (BSH)

Michal has also created various test scripts and their source code is available from this page:

http ://code.google.com/p/browsersec/

The BSH is created and maintained on the Google Code wiki, and thus isn’t available if you’re offline (like on a plane). The wiki doesn’t provide for a clean download with link fixups and all, so I turned to wget and use the below command to cache a local copy (I’m on Ubuntu GNU/Linux)..

wget -E -H -p --convert-links -nH -nd -N -P/PATH/TO/WHERE/YOU/WANT/IT/TO/LOCALLY/LIVE http://code.google.com/p/browsersec/wiki/Main http://code.google.com/p/browsersec/wiki/Part1 http://code.google.com/p/browsersec/wiki/Part2 http://code.google.com/p/browsersec/wiki/Part3

I alias the above gnarly command line to the simple “getbrowsersec” command name (via my .cshrc file), and so whenever I’m online and want to ensure I’ve got the latest revision, I just type “getbrowsersec” and I’m all set. If you live in the Windows world, I’m not sure how you’d do the above natively. I’d install Cygwin, and then one has wget, and can just use the above command.

Strict Transport Security specification

September 19th, 2009

I can’t do a detailed post right now, pointing to announcement message and the spec itself will have to do. This is what I’ve been working on since joining PayPal…

fyi: Strict Transport Security specification


This specification embodies and refines the approach proposed in..

ForceHTTPS: Protecting High-Security Web Sites from Network Attacks

=JeffH sez check it out!

Change of Affiliation: =JeffH -> PayPal InfoSec Team

September 19th, 2009

Ok, my apologies for latency, this is somewhat old news, but I haven’t as yet “announced” it: I landed at PayPal, in the Information Risk Management organization under Michael Barrett (“InfoSec Team” for short), back in March.

I’m very excited to be working at one of the premier web-based organizations and also directly in the security end of things. I now get to be involved in the adoption and deployment of the various online identity and security technologies I’ve been contributing to for many years, as well as contribute to carrying them forward, and also learn some new things.

The latter has been a fair bit of work and steep learning curve as it has involved “web (in)security”, which is a vast swamp involving XSS, CSRF, response-splitting, clickjacking, etc. (hence my crawling into a cave the last several months). And not least, I’ve been very much enjoying meeting and working with key folks involved in web security and browser implementation.

And so with the public announcement of the first web security specification that I’ve contributed to (see next post), it seemed I ought to really pop this frame to the top of the stack and get it out there 8^).

Towards Kerberizing Web Identity and Services

February 4th, 2009

Some colleagues (Josh Howlett, Leif Johansson, RL “Bob” Morgan) and I had the good fortune to help the MIT Kerberos Consortium (MITKC) with some analysis and strategy planning for the (broad) topic of “Kerberos and the Web”, during this last Fall 2008. The main deliverables of this project are this document..

Towards Kerberizing Web Identity and Services

..and this presentation..

Kerberos for the Web: Current State and Leverage Points

..given at the MITKC’s Financial Services Security Summit and MIT Kerberos Consortium Executive Advisory Board Meeting last Fall.

Of course, these documents may not make much sense if one doesn’t know what Kerberos is, so if that’s the case, this brief tutorial ought to be helpful, as well as the Kerberos entry on Wikipedia. Additionally, the MITKC has published a series of Kerberos whitepapers outlining Kerberos’ role(s) in the Big Picture of information systems in general, as well as various best practices.

That said, the MITKC’s announcement of the document provides overall rationale for their Kerberos-on-the-Web project. They have also established a new public mailing list for technical discussions on this topic.

Additionally, here’s the salient portions of the paper’s abstract..

Today authentication and authorization are addressed in an incoherent, and often site-specific, fashion on the Internet and the Web specifically. This situation stems from many factors including the evolution, design, implementation, and deployment history of HTTP and HTTP-based systems in particular, and Internet protocols in general.

Kerberos is a widely-implemented and widely-deployed authentication substrate with a long history in various communities and vendor products. Organizations that currently use Kerberos as a key element of their infrastructure wish to take advantage of its unique benefits while moving to Web-based systems, but have had limited success in doing so.     …

In this paper we outline the evolution of Web Identity and Services and describe the issues surrounding this complex landscape. These issues are captured within a set of more specific requirements that are deemed necessary to satisfy the relevant stakeholders; these requirements are then framed within the context of some general use cases. We then propose and describe a number of activities that leverage Kerberos to realize these improvements, and present an overall strategy and architectural model for working towards a more cohesive and widely deployed Kerberos-based Web authentication infrastructure.

Casual readers may find the section entitled A Short History of Web Identity and Services interesting, while those desiring the gory details as well as the identified opportunities will benefit from reading the entire paper. Here’s the overall summary illustration..

Summary of opportunities for Kerberos and the Web Architecture

Summary of opportunities for Kerberos and the Web Architecture

In concluding, we recommend that in conjunction with developing an overall strategy and architecture with stakeholders, that the MITKC ought to initiate at least these activities..

  • Specify the use of Kerberos with TLS
  • SAML-in-Kerberos: Extend Kerberos to permit the inclusion of a SAML assertion in KDC issued authorization data
  • Kerberos-in-SAML: SAML profile supporting the generation of SAML assertions containing Kerberos tickets
  • Update WS-Security Kerberos Token Profile specification
  • Leverage SAML metadata to enable large-scale Kerberos cross-realm communities”), and
  • Investigate, document and promote existing methods of using Kerberos to authenticate against a SAML identity provider

Discussion of this paper and the MITKC’s overall Kerberos-and-the-Web project occurs on the (new) mitkc-web@mit.edu mailing list. Feel free to subscribe and join in.