The Security Practice

Combating Cybercrime

Hello, Andy Steingruebl here:

We've just published a whitepaper titled "Combating Cybercrime: Principles, Policies, and Programs".

You can read a quick summary at this blog post, or download and read the paper itself.  While we don't believe we have all of the answers to combating crime online, we do believe we've presented a set of principles as well as several workable policy and technology options that will help make progress against this problem.

Please do let us know your thoughts.

Thank you

Web (In)Security: Remediation Efforts - Status and Outlook

Hi, Jeff Hodges and Andy Steinguebl here.

We gave a "status and outlook" talk on the topic of "Web (In)Security: Remediation Efforts" at a major security conference in Feburary.

The thrust of the talk is that currently "the Web" has some issues, and..

• there has been work going on in various fashions to address aspects of this, though it is unfortunately fairly uncoordinated,
  
  
• as a result, there are some "knobs and buttons" you as a web application operator can use today to aleviate some of the issues (and here's how),
  
  
• there are various high-priority issues that are being addressed in various fora, notably the IETF and the W3C, and you can/should participate.

A facsimile of our presentation is here.

Enjoy!

 

 

Do-Not-Track Must First "Do No Harm"

Hello, Brett McDowell here:

Mozilla went on the record over the weekend with their specific proposal for how to implement Do-Not-Track (DNT) mechanisms via HTTP-header (with the goal to enable users to opt-out of Online Behavioral Advertising (OBA) at internet-scale, if they wish).  Here are the relevant links:

Privacy Positioning Blog Post (Alex Fowler):

Firefox Technical Proposal Blog Post (Sid Stamm):

Proposal Itself (header implementation):

Proposal Itself (UI implementation):

Technical Analysis of Do-Not-Track proposals (Mike Hanson):


Mike Hanson's blog post is the best analysis on the topic I've seen so far, but it still fails to call-out anti-fraud tracking explicitly as a behavior that should not be interfered with by DNT.  He lists: advertising, personalization, and metrics as functions DNT should avoid interfering with, but given the nature of the Mozilla DNT proposal, sites still have to implement an interoperable OBA opt-out mechanism to avoid even that level of interference.  Will every browser vendor have their own interface we have to interoperate with to avoid having all "3rd-party tracking" -- which of course doesn't actually mean 3rd-party, but simply means "from domains other than the one in the location bar" -- blocked by their browser?

I continue to be disappointed by the Do-Not-Track discussion as captured by the media and blogosphere for its continued disregard for the security considerations of this new header.  Our concern is not about some geeky, low-level afterthought.  We are talking about a fundamental negative consequence on internet security brought about by an industry-wide knee-jerk reaction to the FTC that is currently poised to remove mission-critical consumer protection mechanisms (commonly used by sites that require user authentication, including but not limited to financial services and commerce) if security considerations remain in the shadows of this policy debate much longer. The internet community must come together and explicitly carve-out anti-fraud tracking as a behavior to sustain, if not embolden, in the post-DNT world.  

Carving-out first-party tracking is a reasonable step that I don't intend to criticize, but it's a blunt instrument that is insufficient for the task.  Anti-Fraud tracking is not always exclusively conducted via first-party cookies, nor is OBA exclusively negated by blocking 3rd-party cookies (as Mike Hanson points out in his post).  Whatever DNT turns out to be, it must be based on a use-and-obligations model, i.e. a mechanism that triggers the required obligation for the specific use being addressed by the mechanism, which is OBA in this case.  I'm pleased to see Mozilla headed in that direction, but there is still a long way to go before we've got this right.  

The core issue is introduced in this sentence from Mike Hanson's post:
"I propose that the user's intent can be captured in a simple rule: If the Do-Not-Track header is present, and the site has a "tracking opt-out" mechanism, the mechanism should be activated. If the site does not have an explicit opt-out mechanism, the user should experience only content from their first-party relationship with the page being viewed."

I interpret the intent of that to mean:

1. Sites must implement an interface between the HTTP "DNT" Header and their current opt-out mechanisms
2. This implementation must be interoperable across all browsers and sites
3. If anything goes wrong and the browser cannot interpret the confirmation from the site that it has implemented it's OBA opt-out mechanism in compliance with the DNT header setting in the browser, then the browser will initiate the "more harmful than helpful" behavior of blocking all but obvious domain-based, first-party content and tracking mechanisms.

Step 3 highlights the nest of issues we need to resolve if we want to ensure the post-DNT-web is better at protecting personal information from unauthorized disclosure than the web we have today.  

Because this is a tractable problem, we are not against the DNT movement per se.  We are against DNT gone wrong.  What we need now is an all-hands standardization effort inclusive of the many proposals, all the various influencers, under a collaborative framework with a proven track record of facilitating timely compromise on thorny standardization issues, to bang out a rough consensus set of policies and protocols for DNT.  This is not a call to stop the DNT effort, but to elevate DNT out of the noise of media coverage and into serious analysis and standardization work... before it's too late to get it right.

The Need for Coherent Web Security Policy Framework(s)

Hi, Jeff Hodges here.

Andy Steinguebl and I presented ths paper at the Web 2.0 Security and Privacy 2010 Workshop..

  The Need for Coherent Web Security Policy Framework(s)

..back in May (abstract below). Since then, we’ve been waving our paper around and pursuing the action items outlined therein with some modest success, which we'll discuss as things develop.

Abstract

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.

 

HTTP Strict Transport Security Happenings -- IETF, Firefox 4.0 beta

Hi, Jeff Hodges and Andy Steingruebl here..

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

Also, we held a successful BoF at IETF-78 Maastricht last month, named "HASMAT" (for "HTTP Application Security Minus Authentication & Transport"), the result being that a new IETF Working Group will be formed (which may be named HASMAT or something else), into which the HSTS spec will land. Once that happens, the spec will likely become a working group item, and thus the filename and URI for that new version will change (just fyi). We'll post about that when it occurs.

In terms of Firefox support, the HSTS implementation has landed in the nightlies (thanks Sid!) and will be included in the next Firefox 4.0 beta. Note that HSTS is already a feature in Google Chrome as of version 4.

Enjoy!

Mozilla Security Blog: HTTP Strict Transport Security

 

 

How Mine Safety is Like Internet Governance

Hello, Andy Steingruebl here:

There was a great piece on NPR  (a link to some of it here: http://www.npr.org/blogs/thetwo-way/2010/04/safety_agency_to_use_ignored_p.html)  the other day about the MSHA (Mine Safety and Health Administration) and how their enforcement against unsafe mines has been sorely lacking.  One key piece of the story is that essentially the statutory authority granted to the MSHA is to close a mine, or a section of it.  They don’t have the power to levy fines for example, or prosecute individuals doing unsafe things.

As a result, their main weapon is essentially the nuclear option against a mine operator.  They are therefore reluctant to use that authority, and so they have instead created a system of letters-of-pending-action or somesuch.  Under these they indicate to a mine operator that they are getting close to a breach of their requirements, and they give them a cure timeframe.  Because mine operators can appeal any judgments, this ends up being a real obstacle to credible enforcement.  Historically we’ve seen the same things from the FAA.  They are loathe to write up formal findings because they have the possibility of causing major harm to an airline, rather than just getting them to modify the offending behavior.

 ICANN has a similar problem with policing their registrars.  historically the only penalty they can impose is removing a registrar’s accreditation.  This is the nuclear option.  They have typically been loathe to fully remove a registrar, and so we end up with bad registrars in the system. We've seen them step up the enforcement recently, but I think these are probably still enforcements against only the most egregious offenders.

The lesson for us in working to craft internet governance and regulations is that we need to understand this dynamic between regulator and regulated-entity, and create flexible schemes that allow the regulator to effectively police, without each policing action being a nuclear option, and thus causing regulated entities to fight every judgment action in court, etc.

Perspectives on "perspectives"

Hello, Andy Steingruebl here:

After the paper a week ago by Chris Soghian and Sid Stamm on the possibility and perhaps high likelihood of a breakdown in the CA trust model due to coerced certificate generation, a lot of attention has focused on how to mitigate this type of attack.

Generally speaking people have been looking to several different solutions to the problem:

1. Detection of changes in a given site's CA or Certificate
2. Allowing a site to indicate its CA policy via some OOB means
3. Alternative means for scoping CA signing rights in browsers so that the trust-root isn't one size fits all.
4. Sites advertising their SSL keys via other means than signing by a CA.

I want to focus on just topic #1 in this post and I will write up some further thoughts on #2 , 3, and 4.

Several solutions to detect changes or variances in a site's certificate have been proposed. One of the most prominent and advocated is the Perspectives work (and Firefox plugin) from CMU.

Perspectives works by having a group of "notary" servers on the internet monitoring certain sites, and capable of telling an end-user whether they have a quorum of agreement on the value presented for a given server's certificate.  If the version of a certificate that your client sees differs substantially from those seen by a number of notary servers, there is some chance you are suffering a MiTM attack.  

These Notary servers can also be used to track the properties of a given certificate over time.  If they notice for example that the certificate at https://www.paypal.com/ is usually singed by Verisign (it is) and is an EV certificate, and all of sudden it is signed by some other small CA, then that may be evidence of something like compelled certificate generation.

Just this last weekend we had some security researchers contact us about a number of certificate fluctuations for https://www.paypal.com.  Over the last few weeks our certificate changed several times, and in one case for very short period of time.  Based on the assumption that certificate fluctuations like this could also be a result of an attacks, the researchers contacted us. (Reminder, we have a contact process for security issues).

Unfortunately, the changes of certificates for www.paypal.com was intentional.  We were testing out some new certificates on the PayPal site, and rolled them out in order, and for a short duration.  All of the certificates were signed by the same CA as usual, but were distinct from each other and did cause fluctuations within the Perspectives tool.

During the recent Global Symposium on DNS Security, Stability and Resiliency the issue of coherency for DNS came up as a metric to track.  One of the hard things to define within the DNS is "right answer" to a query.  As it turns out, the best definition we could come up with was - "Client gets the answer to the query that the zone owner intended."

Which bring me back to the point of this post.  In the space of Web server SSL certificates, the only point of view of correctness that really matters, is what the server intended to publish.  Yes, there is a relying party in this trust relationship (the end user) and they are ultimately responsible for deciding whether to trust a certificate. But the major data point they should consider is what the Site intended, and try to discern that as best they can.

The only party who actually knows what certificate should have been published, is the site owner.  

This means that for certain types of prevention and defense against certain attacks, we need to look for options #2,3,4 above to solve the problem, because the current in-band signaling mechanism isn't always up to the task against certain classes of adversaries, and has certain undesirable failure modes.

New rev of Strict Transport Security (STS) Specification

Hi, Jeff Hodges here.

I have pushed out a new rev (-06) of the Strict Transport Security (STS) Specification, with changes derived from feedback from various folks. This message (HERE) discusses the more major changes.

Note that STS discussion has now moved to the [email protected] mailing list (from the [email protected] list).

There is also a wiki page on which public-web-security@ denizens are working on coalescing various facets of web security, http://www.w3.org/Security/wiki/Main_Page, (including a page on STS).

Strict Transport Security presentation

Hi, Jeff Hodges here.

This evening, I'll be presenting on Strict Transport Security at iSEC Partners' iSEC Open Security Forum. My presentation is HERE. It provides a succinct STS overview and a brief status report on where we are with the effort.

Announcing Strict-Transport-Security Support on www.paypal.com

Hello, Andy Steingruebl here.

I'm pleased to announce that PayPal is the first major internet site to implement the draft Strict-Transport-Security standard.  As of Friday November 6th, 2009 PayPal is supporting the Strict-Transport-Security (STS) mode on our main website, https://www.paypal.com.

As we published back in September when we released the jointly developed spec, STS allows a site to override a web browser's normal protocol preference for HTTP, and instead tells the web browser to convert all attempts to access a given site to use HTTPS.  The draft spec is here.

A few small caveats.

1. Right now we're just supporting this on https://www.paypal.com, not any of our other sites.
2. We've launched with a very small max-age parameter for testing purposes.  We expect that after more extensive testing we will deploy with a much larger max-age value to provide more robust protection for users.
3. This feature is currently supported in the NoScript and ForceTLS extensions for Firefox, and Chrome-4 (currently in beta). We expect other browsers to add the feature in the future.