Archive for the ‘Security’ Category

Monday, March 7th, 2011

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 🙂

Average Rating: 4.4 out of 5 based on 268 user reviews.

Monday, March 7th, 2011

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 🙂

Average Rating: 4.6 out of 5 based on 278 user reviews.

Wednesday, February 23rd, 2011

Susan Landau, with whom I’ve had the pleasure of working and co-authoring some documents (e.g.: a, b, c), has new book that’s now available: Surveillance or Security? The Risks Posed by New Wiretapping Technologies.

Additionally, NPR ran an All Things Considered piece yesterday on the wiretapping topic and interviewed Susan for it.

Also, she’s blogging (here) at the the Huffington Post on these and overall security/policy topics.

=JeffH sez check it out 🙂

Average Rating: 4.9 out of 5 based on 154 user reviews.

Tuesday, 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 🙂

Average Rating: 4.8 out of 5 based on 257 user reviews.

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

Average Rating: 4.6 out of 5 based on 213 user reviews.

Wednesday, December 23rd, 2009

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 🙂

Average Rating: 4.4 out of 5 based on 222 user reviews.

Wednesday, October 22nd, 2008

I found the existing protocol flow diagram in the current OAuth spec..

OAuth Core 1.0
http://oauth.net/core/1.0/

..somewhat hard to follow. So I concocted three separate new ones using the so-called “swimlane” technique that I’m used to.

I posted these to the OAuth list a while back, and a few folks reposted them to their blogs, but no one has yet piped up to say I got anything wrong. But YMMV, there might be bugs in here.

FWIW, I’ve posted them below in case others find them useful. Also, I have them in a single file..

http://identitymeme.org/doc/draft-hodges-oauth-05-figures.txt

..also featuring OpenID and SAML Web Browser SSO Profile diagrams for comparison purposes. Note that in all things protocol, definitions of terms are essential in order to be able to effectively communicate and reason about protocols, so I’ve included key definitions from the OAuth spec in the file.

NOTE: fixed-pitch font required for viewing. Also, wordpress is obviously messing up the diagrams below, and they consequently look sorta lame, here on the blog. This site presently uses an old wordpress install, maybe this will help motivate me to upgrade it. In the meantime, check out the file linked-to above for the best viewing experience 😉

Fig 1: out-of-band consumer setup/config

                                           photos.example.net
                                             +----------+
                                             |          |
                                             | OAuth    |
                                             | service  |
                  printer.example.com        | provider |
                      +---------+            |          |
                      |developer|            |  Sys     |
                      |   of    |            |  Admin   |
                      | OAuth   |            |          |
                      |consumer |            |          |
                      |         |            |   [SP]   |
                      +----+----+            +----+-----+
                           |                      | 
                           | obtain Consumer Key  |
                           | and Consumer Secret  |
                           | [details unspec'd,    |
                           |  performed out-of-   |
                           |  band.]              |
                           |--------------------->| 
                           |< ---------------------|
                           |                      | 
                           |                      |

Fig 2: "Web-based consumer"

The "consumer" is a website or other application that accesses 
the Service Provider on behalf of the wielder (user) of the user agent 
(UA is typically a browser,  but could be some other app).  

Steps 1.n.   "Obtain Unauthorized Request Token"
      2.n.   "User Authorizes Request Token"
      3.n.   "Exchange Request Token for Access token"
      4.n.   UA accessing protected resources at SP
      
      

                                           photos.example.net
                                             +----------+
                                             |          |
                                             | OAuth    |
                   printer.example.com       | Service  |
                       +--------+            | Provider |
                       |        |            |          |
                       | OAuth  |            |[protected|
                       |Consumer|            |resources]|
 +----+                |        |            |          |
 | UA |                |  [RP]  |            |   [SP]   |
 +-+--+                +---+----+            +----+-----+
   |                       |                      |
   | 1.0.  User Agent inter-|                      |
   | acts with Consumer    |                      |
   | site [optional]       |                      |
   |< --------------------->|                      |
   |                       |                      |
   |                       |                      |
   |                       |                      |
   | 1.1.  UA informs/directs                      |
   | Consumer to do something                     |
   | with a resource (e.g.  |                      |
   | a photo) at SP        |                      |
   |---------------------->|                      |
   |                       |                      |
   |                       |                      |
   |                       |                      |
   |                       | 1.2.  Consumer attempts
   |                       | accessing photo at SP|
   |                       |--------------------->|
   |                       |                      |
   |                       |                      |
   |                       | 1.3.  SP replies with |
   |                       | a HTTP 401 containing|
   |                       | a "OAuth" www-authn  |
   |                       | header field         |
   |                       |< ---------------------|
   |                       |                      |
   |                       |                      |
   |                       | 1.4.  Consumer replies|
   |                       | with a request for   |
   |                       | "unauthorized Request|
   |                       | Token" (uRT) via POST|
   |                       | to SP's "request token
   |                       | URL"                 |
   |                       |--------------------->|
   |                       |                      |
   |                       |                      |
   |                       | 1.5.  SP issues uRT & |
   |                       | token secret to      |
   |                       | Consumer.             |
   |                       |< ---------------------|
   |                       |                      |
   |                       |                      |
   |                       |                      |
   | 2.0.  Consumer redirects                      |
   | UA to SP "User Author-|                      |
   | ization URL" including|                      |
   | the uRT.               |                      |
 +<- - - - - - - - - - - - |                      |
 .  | (indirected via UA)   |                      |
 .  |                       |                      |
 +-------------------------+--------------------->|
   |                       |                      |
   |                       |                      |
   |                       |                      |
   |                       |                      |
   | 2.2.  User authenticates with the Service     |
   | Provider (optional,  methods vary,  realization|
   | is out of scope)                             |
   |< ============================================>|
   | 2.3.  User grants or declines permission      |
   | for the Service Provider allow Consumer      |
   | access to the resource (e.g.  photo).          |
   |                       |                      |
   |                       |                      |
   |                       |                      |
   |                       |                      |
   | 2.4.  If permision granted,  UA redirected back|
   | to Consumer's "Callback URL",  conveying the  |
   | uRT.                   |                      |
 +< - - - - - - - - - - - - - - - - - - - - - - - -|
 .  | (indirected via UA)   |                      |
 .  |                       |                      |
 .  |                       |                      |
 +------------------------>|                      |
   |                       |                      |
   |                       |                      |
   |                       |3.0.  Consumer requests|
   |                       |Access token,  supplies|
   |                       |uRT.                   |
   |                       |--------------------->|
   |                       |                      |
   |                       |                      |
   |                       |                      |
   |                       |3.1.  SP grants Access |
   |                       | Token.                |
   |                       |< ---------------------|
   |                       |                      |
   |                       |                      |
   |                       |4.x.  Consumer uses the|
   |                       |Access Token,  Access  |
   |                       |Token Secret,  Consumer|
   |                       |Key,  and Consumer Secret
   |                       |to make authenticated |
   |                       |request(s) to the Service
   |                       |Provider.              |
   |                       |=====================>|
   |                       |           .           |
   |                       |           .           |
   |                       |           .           |
   |                       |                      |



Fig 3: “desktop-based consumer”


this is case where user is wielding some app that is both a UA and a Consumer.


                                             +----------+
                                             |          |
                                             | OAuth    |
                                             | service  |
 +--------+                                  | provider |
 |        |                                  |          |
 |Desktop-|                                  |[protected|
 |based   |                                  |resources]|
 |Consumer|                                  |          |
 |        |                                  |          |
 | UA     |                                  |   [SP]   |
 +-+------+                                  +----+-----+
   |                                              |
   | 1.  Consumer requests "unauthorized Request   |
   | Token (uRT)" with POST to SP's "request token"
   | URL.                                          |
   |--------------------------------------------->|
   |                                              |
   |                                              |
   | 1.1.  SP issues uRT and Token Secret to       |
   | consumer.                                     |
   |< ---------------------------------------------|
   |                                              |
   |                                              |
   |                                              |
   | 1.2.  User authenticates with the Service     |
   | Provider (optional,  methods vary,  realization|
   | is out of scope)                             |
   |<============================================>|
   | 3.  User grants or declines permission        |
   | for the Service Provider to issue Access     |
   | Token.                                        |
   |                                              |
   |                                              |
   |                                              |
   |                                              |
   | 4.  Service Provider authorizes the uRT to be |
   | exchanged for an Access Token and secret.     |
   |< ---------------------------------------------|
   |                                              |
   |                                              |
   |                                              |
   | 5.  Consumer exchanges the uRT and secret     |
   | for an Access Token and Secret.               |
   |--------------------------------------------->|
   |< ---------------------------------------------|
   |                                              |
   |                                              |
   |                                              |
   | 6.  Consumer uses the Access Token,  Access    |
   | Secret,  Consumer Key,  and Consumer Secret    |
   | to make authenticated request(s) to the Service
   | Provider                                     |
   |<============================================>|
   |                      .                        |
   |                      .                        |
   |                      .                        |
   |                      .                        |
   |                      .                        |
   |                      .                        |
   |                                              |

Average Rating: 4.4 out of 5 based on 189 user reviews.

Monday, January 21st, 2008

Eve (aka xmlgrrl) posted the following bit of musing today..

Circles of trust: disaster? or really bad idea?
http://www.xmlgrrl.com/blog/archives/2008/01/21/circles-of-trust-disaster-or-really-bad-idea/

..which I tend to think hits the proverbial nail pretty squarely on the head wrt “open internet”, “trust all comers”, and “trust circles”.

One very small, detail-level comment I have on her post is that where she writes..

(where users are okay with this sort of back-channel communication)

..I would instead make it explicitly clear that “users” sometimes don’t have any direct say with respect to the machinations of the IT department on their behalf. Hence I would write it as..

(where users are okay with this sort of back-channel communication, or where they don’t have any say (e.g. in an enterprise deployment))

Note I don’t feel that the latter is necessarily a good thing, but it’s reality in corporate, governmental, and education worlds (at least), and no amount of attesting that “I want to own my identity data!” is going to change it any time soon (admittedly unfortunately). Besides one’s identity, outside of one’s own thoughts, “..is a story“, as Bob Blakley noted a while back, but has been understood for quite a while by social scientists and philosophers (see, for example, Erving Goffman).

But I digress… 😉

Average Rating: 4.8 out of 5 based on 269 user reviews.

Monday, January 21st, 2008

I’ve done a modest editorial and copy editing update to the OpenID SAML technical comparison document announced earlier. Going forward, the latest rev will be available via this URL:

http://identitymeme.org/doc/draft-hodges-saml-openid-compare.html

Average Rating: 5 out of 5 based on 218 user reviews.

Monday, December 17th, 2007

Over the past couple of years quite a few folks have asked me, and I’m sure others, “what’s the salient differences between OpenID and SAML?” So earlier this year I began hacking together a technical comparison of the two. It’s an interesting exercise comparing two Web SSO protocols, even one as ostensibly simple, and straightforwardly specified, as OpenID. It turns out to be a fairly complex task given all the different facets inherent in authentication protocols in general, and in web-, i.e. HTTP-based, protocols (and profiles thereof) in particular. And also given the various audiences affected by such protocols: implementors, deployers, end users, and protocol designers.

The resultant comparison paper, “Technical Comparison: OpenID and SAML – Draft 05” seems to me to be at a stage where it can be shared widely (i.e. on the web 🙂 ), here it is..

http://identitymeme.org/doc/draft-hodges-saml-openid-compare-05.html

..For many readers, sections 1, 2, and perhaps 3 ought to cover things. For those necessarily interested in gory, really geeky details, parts or all of section 4 will be of interest. Note that this is still a “draft“–there are various items, especially in section 4, that are not as yet evaluated as thoroughly as I’d like, or at all (as yet).

I’ve tried as much as possible to provide an objective comparison. It’s admittedly difficult given I’ve been intimately involved in SAML’s gestation since essentially the very beginning. It’s also a technically difficult comparison because of the differing design centers of OpenID and SAML, as well as differing specification styles, and thus the difficulty in presenting the comparison to the reader, not to mention attempting to be “balanced“.

So, I hope this paper will prove at least somewhat enlightening and useful to the multifaceted “identity” community out there, and to those shepherding websites who are wondering what these two oft-mentioned beasts are, how’re they’re different/similar/alike, and also nominally how they work.

=JeffH sez check it out.

Average Rating: 4.6 out of 5 based on 189 user reviews.