headers
Peter Watkins | 1 Sep 2004 18:43
Picon

Re: Re: SSLv2 clients? Rant: Can we finally put a stake through the heart of SSLv2?


Thanks, Tim.

On Tue, Aug 31, 2004 at 04:50:27PM -0400, Tim Dierks wrote:
> On Tue, 31 Aug 2004 12:26:50 -0400, Peter Watkins <peterw <at> usa.net> wrote:
> > Given the recent Netscape NSS advisory
> > (http://xforce.iss.net/xforce/alerts/id/180), I'd like to (finally)
> > disable SSLv2 on my company's https servers. I know that'll mean

which are, perhaps obviously, iPlanet/SunONE httpds

> If you disable support for accepting SSLv2 client hellos, you will not
> be able to talk to anyone who has SSLv2 enabled, regardless of how
> recent their browser is. However, you may be able to disable SSLv2
> handshakes while still accepting SSLv2 client hello messages. If you

This is an implementation-specific question. Nelson, do you know if
disabling "ssl2" in server.xml disables SSLv2 client hello support?

It would seem rather unwise for an SSLv3 or TLSv1.0 server application
not to accept SSLv2 client hellos at this point, since my reading of
the appendices of the SSLv3 spec (http://wp.netscape.com/eng/ssl3/3-SPEC.HTM ?)
and TLS 1.0 RFC (RFC 2246) is that a client that supports SSLv2 as 
well as SSLv3 or TLSv1.0 is supposed to include an SSLv2 client hello.
Both iPlanet Web Server 6.0 and SunONE Web Server 6.1, when configured
with SSLv2 "disabled" accept connections from Mozila 1.7.x clients 
that have SSLv2, SSLv3, and TLS enabled. Presumably[0] Mozilla is following
the TLS and SSLv3 specs and including an SSLv2 client hello, yet it's
still able to establish a SSLv3/TLS connection with the httpd.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Tim Dierks | 1 Sep 2004 19:14
Picon

Re: Re: SSLv2 clients? Rant: Can we finally put a stake through the heart of SSLv2?

On Wed, 1 Sep 2004 12:43:43 -0400, Peter Watkins <peterw <at> usa.net> wrote:
> On Tue, Aug 31, 2004 at 04:50:27PM -0400, Tim Dierks wrote:
> > On Tue, 31 Aug 2004 12:26:50 -0400, Peter Watkins <peterw <at> usa.net> wrote:
> > > Given the recent Netscape NSS advisory
> > > (http://xforce.iss.net/xforce/alerts/id/180), I'd like to (finally)
> > > disable SSLv2 on my company's https servers. I know that'll mean
> 
> > If you disable support for accepting SSLv2 client hellos, you will not
> > be able to talk to anyone who has SSLv2 enabled, regardless of how
> > recent their browser is. However, you may be able to disable SSLv2
> > handshakes while still accepting SSLv2 client hello messages. If you
> 
> Both iPlanet Web Server 6.0 and SunONE Web Server 6.1, when configured
> with SSLv2 "disabled" accept connections from Mozila 1.7.x clients
> that have SSLv2, SSLv3, and TLS enabled. Presumably[0] Mozilla is following
> the TLS and SSLv3 specs and including an SSLv2 client hello, yet it's
> still able to establish a SSLv3/TLS connection with the httpd.

Can you still connect with a client which has SSL 3 and TLS disabled?
I know Mozilla Firefox allows you to do this. If you cannot handshake
in this situation, it seems clear that you have disabled SSLv2 while
continuing to have the ability to negotiate SSL 3.0 & TLS with clients
who have SSLv2 enabled. However, based on my reading of the advisory
you referred to, the problem may be in SSLv2 client hello parsing
(there is a reference to "SSLv2-Client-Hello-Overflow"). This would
imply that you'll still be vulnerable unless you disable SSLv2 client
hellos, and with them, support for any client with SSLv2 enabled.

> > do this, I believe you will support any browser which supports SSL
> > 3.0, which should be any browser of  the last 5 years or so. You
(Continue reading)

Permalink | Reply | 1 comment |
headers
Julien Pierre | 2 Sep 2004 02:11
Picon

Re: SSLv2 clients? Rant: Can we finally put a stake through the heart of SSLv2?

Peter,

Peter Watkins wrote:

>This is an implementation-specific question. Nelson, do you know if
>disabling "ssl2" in server.xml disables SSLv2 client hello support?
>  
>
No, it does not. This setting only prevents the SSL2 protocol from being 
successfully negotiated between server and client, not SSL2 client hello 
messages from being processed by the server.

>Unfortunately I'm not sure if that info is available to me via the
>server's API. 
>
It's been a long time since I worked on web server - I have been on NSS 
the past few years. Check the NSAPI documentation. There should at least 
be calls to query the cipher suite on the socket, even if there isn't a 
call to query the SSL/TLS protocol version . But querying the cipher 
suite should be sufficient for you to tell if SSL2 is negotiated, since 
the SSL2 and SSL3/TLS cipher suites are different.
Attachment (smime.p7s): application/x-pkcs7-signature, 3348 bytes
Permalink | Reply | 0 comments |
headers
Julien Pierre | 2 Sep 2004 03:47
Picon

Re: SSLv2 clients? Rant: Can we finally put a stake through the heart of SSLv2?

Tim Dierks wrote:

>who have SSLv2 enabled. However, based on my reading of the advisory
>you referred to, the problem may be in SSLv2 client hello parsing
>(there is a reference to "SSLv2-Client-Hello-Overflow"). This would
>imply that you'll still be vulnerable unless you disable SSLv2 client
>hellos, and with them, support for any client with SSLv2 enabled.
>  
>
The problem is in the code of the v2 client helo message parsing that is 
specific to handshaking for the SSLv2 protocol. If your client sends a 
v2 HELO but negotiates SSL v3 or 3.1, then the problem code doesn't get 
invoked on the server-side. But if you send a v2 HELO and negotiate v2, 
then the server must be setup to disallow SSL2 handshakes in order to 
not invoke the problem code. Therefore,  disabling SSLv2 client helo 
parsing is not necessary; nor is it possible. The NSS library does not 
actually give you an option to application developers to disable SSLv2 
client helo. It will always parse all types of client helo .

What is configurable is which SSL versions are accepted for a handshake, 
on both client and server side. It is up to applications to configure 
which protocol they accept by calling the proper NSS functions. The 
default when you create a new SSL socket with NSS is to have all of SSL 
v2, 2.0 and 3.1 protocols enabled. It's up to each application (both 
client and server) to then set their preferences and override the 
default settings, based on their GUI (for mozila) or config file (for 
servers). Some very old applications have made incorrect assumption 
about the default protocols that NSS enables on a new socket, and 
therefore may have leave SSL2 accidentally enabled and be vulnerable to 
the SSL2 attack unknowingly. I recommend that everybody upgrades to the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Avinash Agarwal | 2 Sep 2004 12:51

Eap PEAP phase2 query

Hello all, 
 I'm  implementing EAP PEAP on my radius server and needed some
clarification 
with EAP-PEAP phase2. 

The first message for phase-2 in peap needs to be a request identity.
What I'm doin is..
1) Create EAP packet(5 bytes)
{
code = 1;
id = < some id>
length =5
type = 1 <req identity>
} eappkt

2) create MAC of eappkt using server_write_mac
3) concatenate eappkt + MAC
4) encrypt with server_write_key
5) add to TLS APP data and send?

could someone tell me if this is ok?

Regards,
Avinash
Permalink | Reply | 0 comments |
headers
Pasi.Eronen | 2 Sep 2004 14:18
Picon

RE: WG Last Call: The TLS Protocol Version 1.1

Overall, I'm happy with the document. It's quite well written, and
especially if you are patient enough to start reading from the
beginning, you'll get a good picture of how TLS works and how to
implement it.

Some comments below:

-  Section 1: bulleted lists look like "- - The connection ...";
   remove second dash (same in Section 7.3)

-  Section 1: add period before "The keys for this..."

-  Section 3 about version compatibility should be updated to 
   take TLS 1.1 into account.

-  Section 6.1: "The security parameters for the pending states can 
   be set by the TLS Handshake Protocol, and the Handshake Protocol
   can selectively make either of the pending states current, ..."

   Second reference to Handshake Protocol should be change cipher 
   spec protocol?

-  Section 6 says that we have four protocols over the record
   layer, but Section 7 says that the TLS handshake protocol
   consists of three subprotocols, one of which is also called
   the handshake protocol. This recursive definition might be
   some kind of hidden reference to GNU, but it's not too helpful
   for the reader :-)

   Suggestion: rename section 7 "Handshake-related protocols",
(Continue reading)

Permalink | Reply | 1 comment |
headers
Nelson Bolyard | 2 Sep 2004 22:46
Favicon

Re: SSLv2 clients? Rant: Can we finally put a stake through the heart of SSLv2?

Peter Watkins wrote on 2004-09-01, 09:43:

> > > Given the recent Netscape NSS advisory 
> > > (http://xforce.iss.net/xforce/alerts/id/180), I'd like to (finally) 
> > > disable SSLv2 on my company's https servers. I know that'll mean 
> 
> which are, perhaps obviously, iPlanet/SunONE httpds 
[snip]
> This is an implementation-specific question. Nelson, do you know if 
> disabling "ssl2" in server.xml disables SSLv2 client hello support? 

The NSS libraries are used in many client and server applications, 
including several brands of web servers, LDAP directory servers, SMTP, 
IMAP, and POP servers, NNTP servers, and probably others of which I am
unaware.  (Since NSS is open source, we simply do not know all the 
products that use it.)

With respect to disabling SSL2, the NSS library APIs allow CLIENT apps to:
a) disable SSL2, but still send SSL2-format client-hellos that negotiate
   SSL3/TLS to servers with which no session is presently established, or
b) disable SSL2 and never send ssl2-format client-hellos.

With respect to disabling SSL2, the NSS Library APIs allow SERVER apps to
disable the negotiation of SSL2, but they do not permit the app to 
disable the acceptance of SSL2-format client hellos that negotiate 
SSL3/TLS.  Disabling SSL2 negotiation at the API is sufficient to make
the library invulnerable to this attack.  

The question, then, is how to get an NSS-based server product to invoke 
the NSS library APIs to disable SSL2.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sheueling Chang | 3 Sep 2004 04:28
Picon

Re: Moving forward on draft-ietf-tls-ecc-*

William,

I hope that Bodo Moeller's comprehensive response on 8/30/04
has addressed your concern.

Section 5.7 of draft-ecc-06

    >Actions of the recipient:
    >The server retrieves the client's ephemeral ECDH public key from the
    >ClientKeyExchange message and checks that it is on the same elliptic
    >curve as the server's ECDH key.

requires a recipient to validate that a public key point is
in the group. This validation code is in OpenSSL.
No IP issues have been raised since 9/2002 on this validation code.
Personally, I am not aware of any IP that precludes this checking.
As Bodo mentioned:
 > The idea of verifying that a given purported group element is in
 > fact an element of the group in question has been around for quite a
 > while; see e.g. Don Coppersmith, "Cheating at mental poker",
 > CRYPTO '85, LNCS 218 (that's the same conference where Victor Miller
 > proposed using elliptic curves for cryptography).

The technique for detecting and avoiding small-subgroup attacks,
which was described in Certicom patents US 5,933,504 and
continued in US 6,563,928, was not needed for ECDH as used in
draft-ietf-tls-ecc-06.txt. (neither for DH).

This is because when a server public key is in a certificate or
signed by a certified key, the DH or ECDH key exchange is not subject
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eunjin Jung | 4 Sep 2004 02:03
Picon

Statistics of certificate chain length in TLS?

Hi,

I'm a Ph.D student in UT Austin doing research on
certificate systems. I am particularly interested
in the use of certificate chains, and am looking
for any statistics on how many certificates are used
in TLS in practice. Could anyone give me some pointers?

Thanks in advance,
Eunjin
--

-- 
-------------------------------------- 
 Eunjin Jung, aka EJ
 http://www.cs.utexas.edu/users/ejung
--------------------------------------
Permalink | Reply | 0 comments |
headers
Peter Gutmann | 5 Sep 2004 11:06
Picon
Picon
Picon
Favicon

Comments on the TLS 1.1 draft

Given that this is probably my last chance to gripe about things:

Section 6.2.1 says:

  Application data is generally of lower precedence for transmission than
  other content types and therefore handshake records may be held if
  application data is pending.

Wouldn't application data be of higher precedence if it can pre-empt handshake
data?

Section 6.3, this is somewhat misleading, the cipher spec that requires the
most key material isn't 3DES_EDE_CBC_SHA but AES_256_CBC_SHA, even if it's
defined elsewhere.

(Shouldn't the RFC 3268 suites be folded into the TLS 1.1 spec?  It seems like
 a good idea to have them all in the same document, at the moment TLS 1.1
 doesn't even hint that there are AES suites, and in particular suites that
 actually require more keying material than 3DES_EDE_CBC_SHA).

More section 6.3: The mention of IV generation for < TLS 1.1 has been
completely excised, apart from a passing mention elsewhere that explicit IVs
are new for TLS 1.1.  Shouldn't there be some mention of this somewhere,
either in section 6.3 or in an appendix?  There are various historical notes
covering older usage (e.g. the lack of a length field in RSA encrypted data in
SSLv3), but the only way to find out about previous IV usage is to dig up old
copies of the spec.  Note that this change also applies to the keying-material
note, since with the additional implicit IV data the size increases still
further.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane