RE: ACTION-426: strong and weak TLS algorithms (incorporateISSUE-128text)

Ideally agents should check key strength as well as cipher strength.

As a current example, the Debian OpenSSL random number generator flaw
resulted in hundreds of thousands of possible weak key pairs. However,
only 151 have been discovered so far in use on the Internet:
http://codefromthe70s.org/sslblacklist-badcerts.asp

Some recognizable domains on the list are: redhat.com, harvard.edu,
.buffalo.edu, patownsend.com, ietf.org, spidynamics.com. Note that two
of them are information security companies.

At least a couple browser add-ons, SSL Blacklist (FF) and heise SSL
Guardian (IE), exist to automatically detect and warn when a web browser
connects to an HTTPS site that is using a certificate with a weak public
key (e.g. generated by Debian OpenSSL with the random number generator
flaw).

The weak certificate list is about 60 megabytes, uncompressed.
"openssl-blacklist" source package in Ubuntu
https://launchpad.net/ubuntu/+source/openssl-blacklist/

There is also a clever use of DNS to provide checking against the black
list.  The DNS-based database is implemented via the
modulusblacklist.org domain. This is a simple domain whose name servers
answer with a certain A record (127.0.0.2) when known-bad "hosts" are
queried, such as
020b881ecc8bd1fb12b7d5361c9a90e339203666.modulusblacklist.org. When it
receives requests for modulus hashes that it does not know about, it
responds with a different A record (127.0.0.3), signaling that the key
is not blacklisted.

SSL Blacklist 3.0 for Firefox
http://codefromthe70s.org/sslblacklist.asp

heise SSL Guardian for MS-Internet Explorer
http://www.heise-online.co.uk/security/Heise-SSL-Guardian--/features/111
039 

FYI Mike

-----Original Message-----
From: public-wsc-wg-request@w3.org [mailto:public-wsc-wg-request@w3.org]
On Behalf Of Doyle, Bill
Sent: Monday, July 14, 2008 1:52 PM
To: Thomas Roessler
Cc: stephen.farrell@cs.tcd.ie; pbaker@verisign.com; johnath@mozilla.com;
yngve@opera.com; public-wsc-wg@w3.org
Subject: RE: ACTION-426: strong and weak TLS algorithms
(incorporateISSUE-128text)


This is really quite late response but in looking at

Network Working Group                                          T.
Dierks
Request for Comments: 4346
Independent
Obsoletes: 2246                                              E.
Rescorla
Category: Standards Track                                     RTFM,
Inc.
                                                              April
2006


              The Transport Layer Security (TLS) Protocol
                              Version 1.1


Appendix 5 notes ciphersuite definitions that are not considered secure

http://tools.ietf.org/html/rfc4346#appendix-A.5

 

-----Original Message-----
From: Thomas Roessler [mailto:tlr@w3.org]
Sent: Wednesday, June 11, 2008 2:08 PM
To: Doyle, Bill
Cc: stephen.farrell@cs.tcd.ie; pbaker@verisign.com; johnath@mozilla.com;
yngve@opera.com; public-wsc-wg@w3.org
Subject: Re: ACTION-426: strong and weak TLS algorithms
(incorporateISSUE-128text)

For context:
http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#def-strong-algos

On 2008-06-11 13:46:06 -0400, Bill Doyle wrote:

> I like it -

Thanks.

> SSLv3 is deprecated - supported ciphers are no longer strong enough, 
> industry moves forward.

I'm happy to add this one to the list of things that you really must not
consider strong.  Which brings me to another point:  It's probably worth
using RFC 2119 verbiage when we enumerate what's considered weak or
strong.  I've made that change in the latest version, and would actually
be tempted to change this further to say
that:

	SSLv3 SHOULD NOT be considered strong.

I also wonder if it's worth saying a word about MD5-based certs.

> Is the IETF grouping ciphers in a way that enables weak ciphers to be 
> noted? Export grade is easy, not sure about others.

Not that I'd know.

Cheers,
--
Thomas Roessler, W3C  <tlr@w3.org>

Received on Wednesday, 16 July 2008 16:40:33 UTC