This is just another installment of how the freedom of expression and scientific research is being sacrificed on the altar of "public safety" and "property rights". From the CNET article:

"A federal judge on Saturday granted the Massachusetts transit authority's request for an injunction preventing three MIT students from giving a presentation about hacking smartcards used in the Boston subway system."

  To summarize this incident: a couple of student find a giant security hole is a publicly financed payment system. They inform the authorities and involved parties to given them a change to work on the situation. The faceless bureaucrats respond in the way any large (and thus inefficient) organization will respond: ignorance and disbelief. The students follow the time-honored tradition of publicizing their results and suddenly the gears spring into actions: federal courts, FBI, and preliminary injunctions appear. The official reason is "public safety", but everyone involved knows that this is just a very lame excuse. In truth, it is the desire of an inadequately powerful state-sponsored enterprise to hide their incompetence and silence their "subjects".

  The fact that this can even be done is the availability of unconstitutional laws (at least in spirit) like the DMCA and similar utterly meritless legislation. Coming from Europe, I am used to the frequent oppression of freedoms, even today. So far, the U.S. has been setting an example of how e.g. the freedom of expression should be interpreted. This gag order by a federal judge in Boston (sic!) is an untenable limitation of this right. It goes against some of the most fundamental principles enshrined in the Constitution and the Bill of Rights. 

  For more information, check the EFF website. 

tags: civil rights, freedom of speech, mbta

I just laughed out loud:

Go King Homer I. of Spain!

tags: humor, simpsons

  Last year we announced an experiment at Sun: in order to gather more information about the operational characteristics of "user-centric" identity technologies, we decided to roll out an OpenID provider for Sun employees. This OpenID provider was intended to be used by Sun employees for personal usage at various OpenID sites that have been popping up at some places.

  This experiment involved various parts of the company, including field people, products folks, the security team, and our Chief Privacy Officer. We negotiated a number of requirements for our experiment: employee privacy must be maintained at all times, the system must not interfere with any other Sun authentication or business system, etc. All this was quite achievable and we passed the--albeit lax, since it was an experiment--security and privacy reviews, the focus of which was the protection of Sun employees and property.

  The weakness in Debian-generated certificates and the recent DNS cache poisoning attack vector resulted in a triple whammy: weak certificates, broken DNS, weak protocol. After Ben's report last week, we revisited the current design of the service and came up with a few recommendations. Mark Wilcox notes that my list could be hard to follow, especially for non-technical users. To some extend^[1] I do agree with him, so we decided to take additional steps on our end to improve security:

  The very core of these changes lies in the idea that we are introducing HTTPS based OpenIDs for our users. In OpenID 1 and 2, a RP normalizes any identifier without scheme prefix into an unsecured HTTP based identifier. Only a prefixing the OpenID identifier with the https:// scheme will result in discovery over an TLS secured transport channel. This looks a lot "geekier" than the somewhat more appealing "naked" OpenID identifiers, but as a result of this change, the lookup will now be handled completely over server-authenticated channels. 

  In order to make this approach useful, we would need the cooperation of OpenID RPs: in the current specs, http://openid.sun.com/user and https://openid.sun.com/user are two separate entities, which--in my opinion--makes no sense. If RPs would start recognizing these two identifiers as the same entity, it would help improve the security of the OpenID protocol in a quite significant way, since users could easily migrate from the broken insecure HTTP discovery protocol over to the somewhat more secure HTTPS transport.

  Obviously, this cannot address the key-reandomness weakness, but then ... only time can. Meanwhile we have to rely on CRLs and OSCP checking for certificate revocation.

  UPDATE: The approach outlined above might be criticized for equating two URI that are not equivalent (https://... and http://...). I appreciate this from a principal point of view, but extreme time require extreme measures .

  A reasonable way to address the potential security implication for current https://.. identifiers would be for the RP to perform a one-time security upgrade: assuming that the RP recognizes a particular claimed_id e.g. http://openid.sun.com/user. Whenever there is a login with the same identifier over HTTPS (i.e. claimed_id is https://openid.sun.com/user in the example), the RP can 'upgrade' the account to an HTTPS-only account.

  On the OP side, any account for https://x.y.z should trigger the complete block for any http://x.y.z ids.

  Thanks to John Bradley for some stimulating discussions on these issues.

tags: OpenID security transport security

[1] Mark mentions OAAM's strong authenication and risk based authentication technologies as potential solutions for OpenID's weaknesses. Maybe it is because I am not familir with this product, but I cannot see how OAAM can help with the weaknesses that occur through using HTTP (as opposed to HTTPS) for discovery. Likewise, socially engineered attacked can be effective in circumventing stronger authentication mechanisms (such as pictures or virtual keyboards) for less technology-sophisticated users: instead of their image, the rogue OP displays an error message along the lines of "Sorry, your personal image is currently unavailable due to maintenance. Please use standard authentication in the meantime." This might not work with all users, but I know enough folks who would login also with the "standard authentication" scheme.

With the recent news about the DNS cache vulnerability, users are more exposed than ever to potential security attacks, including phishing or pharming attacks, that apply to OpenID as well as other network systems. For example, the ability to redirect DNS requests through cache poisoning opens the door to a significant OpenID security risk: if the OpenID provider is not employing TLS with server-side authentication — preferably mutual authentication — any affected DNS server could redirect the client to a pharming site that looks like the user's real OP, but is not. If OpenID required transport and authentication over HTTPS, this would be less of a problem.

In order to limit the risk, we are advising the users of our OpenID@Work provider to make sure that they follow these guidelines, which might be useful for others, as well:

• Make sure that you systems are fully patched.
  
• Verify that the DNS server you use (usually provided by your ISP) is patched and not subject to DNS cache poisoning. You can verify this at Dan Kaminsky's web site. If you find that your ISP has not down their job, complain. Loudly.
  
• Use certificate revocation lists. These list contain the serial numbers of revoked certificates and they can be easily consumed by most modern browsers. For the SunPKI list, just point your browser to http://www.sun.com/pki/pkismica.crl and make sure that your browser refreshes it regularly. Other companies have their own CRLs (e.g. Verisigns are here).
  
• Be extra careful when accessing your authentication web site: openid.sun.com can easily be mistaken for open1d.sun.com or openid.sun.com.uk.
  

In addition, we recommend that Sun employees use the corporate VPN for all sensitive corporate business, and — obviously — not use the experimental OpenID@Work authentication service, or any OpenID authentication service, for anything of value.

UPDATE: The Sun PKI CRLs is also here, which is the official distribution point for Sun/Verisigns issued certificates. In addition, these certificate support OCSP verification at http://ocsp.verisign.com.

Ben Laurie and Robin Wilton also published information relating to the weaknesses of OpenID.

tags: openid dns cache poisoning security