IdentityMeme.org

RFC6125 “TLS/SSL Server Identity Check” (aka “TLS Server ID Check“, “SSL Server ID
Check“, “TLS/SSL Server ID Check“, “SSL Server ID“) is now available:

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)

http://tools.ietf.org/html/rfc6125

Alas, we messed up by not including this “short form” title directly in the spec:

TLS/SSL Server Identity Check

But hopefully people will know what spec is meant if someone uses that short-form title.

I’ve written about the spec and its background before:

of TLS/SSL Server Identity Checking

Although we produced the spec without a formal working group, many people contributed to it one way or another. From the Contributors and Acknowledgments sections:

The following individuals made important contributions to the text of this document: Shumon Huque, RL ‘Bob’ Morgan, and Kurt Zeilenga.

The editors and contributors wish to thank the following individuals for their feedback and suggestions: Bernard Aboba, Richard Barnes, Uri Blumenthal, Nelson Bolyard, Kaspar Brand, Anthony Bryan, Scott Cantor, Wan-Teh Chang, Bil Corry, Dave Cridland, Dave Crocker, Cyrus Daboo, Charles Gardiner, Philip Guenther, Phillip Hallam-Baker, Bruno Harbulot, Wes Hardaker, David Harrington, Paul Hoffman, Love Hornquist Astrand, Henry Hotz, Russ Housley, Jeffrey Hutzelman, Cullen Jennings, Simon Josefsson, Geoff Keating, John Klensin, Scott Lawrence, Matt McCutchen, Alexey Melnikov, Subramanian Moonesamy, Eddy Nigg, Ludwig Nussel, Joe Orton, Tom Petch, Yngve N. Pettersen, Tim Polk, Robert Relyea, Eric Rescorla, Pete Resnick, Martin Rex, Joe Salowey, Stefan Santesson, Jim Schaad, Rob Stradling, Michael Stroeder, Andrew Sullivan, Peter Sylvester, Martin Thomson, Paul Tiemann, Sean Turner, Nicolas Williams, Dan Wing, Dan Winship, and Stefan Winter.

Thanks also to Barry Leiba and Ben Campbell for their reviews on behalf of the Security Directorate and the General Area Review Team, respectively.

The responsible Area Director was Alexey Melnikov.

(i.e. 59 people besides PeterSA and myself (wow))

As I’ve previously mentioned, I’ve been working on a specification for “TLS/SSL Server Identity Checking” along with Peter Saint-Andre.

We’ve now heard back from the RFC Editor, and we’re in the so-called “AUTH48 state” where we, the spec’s authors/editors, work with the RFC Editor folks to turn the Internet-Draft into a RFC.

At this point we know the RFC number-to-be: 6125.

So, we’re close to getting this thing out the door, whew.

There’s been various fundamental issues with “HTTP cookies” for ages, e.g. technically and policy-wise (i.e. privacy). The two extant formal specifications of cookies, IETF RFCs 2109 and 2965, as well as the original informal and incomplete “Netscape cookie spec”, have not been implemented uniformly across browsers and servers. Thus how cookies are actually constructed, parsed, and used in practice has been essentially technical folklore. Anyone wanting to craft a new browser or some other application or tool that needs to consume or send cookie headers had to reverse engineer how the browsers were actually doing it as there wasn’t (until now) an accurate specification an implementer could use for reference. This has led to divergence on edge-cases for cookies within various browsers, servers, and other tools.

We’ve been working with browser, server, and web app folk in an IETF working group, “httpstate“, to rectify this, and the draft spec was recently approved for publication as an IETF RFC at the “Proposed Standard” maturity level. This spec differs from the prior specs in that it specifies how cookies are actually used on the Internet today. Anyone crafting a new client or server can implement the spec and have an interoperable implementation as a result.

This is great in that getting this finally explicitly documented will be a key underlying piece of moving “the Web“, and the wider Internet its built upon, on towards its next stage(s). Hopefully, browsers and servers can now converge their “cookie behaviors”

Our more detailed blog post (which includes some history) is here..

‘HTTP State Management Mechanism’ to Proposed Standard
http://www.thesecuritypractice.com/the_security_practice/2011/03/http-state-management-mechanism-to-proposed-standard.html

=JeffH sez check it out

We have a blog post over at my work cohort’s blog, w.r.t. a recent preso we gave, here’s the link…

Web (In)Security: Remediation Efforts - Status and Outlook
http://www.thesecuritypractice.com/the_security_practice/2011/03/web-insecurity-remediation-efforts-status-and-outlook.html

Check it out

[ 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, 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.

Details are over here..

http://www.thesecuritypractice.com/the_security_practice/2009/12/new-rev-of-strict-transport-security-sts-specification.html

=JeffH sez check it out

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)
http://code.google.com/p/browsersec/wiki/Main

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.