headers
Eric Rescorla | 11 Sep 2002 17:02

ANNOUNCE: ssldump: an SSL protocol analyzer v 0.9b3

ANNOUNCE: ssldump: an SSL protocol analyzer v 0.9b3
Version 0.9b3

http://www.rtfm.com/ssldump/

RTFM, Inc. is pleased to announce the availability of ssldump 0.9b3
ssldump is an SSLv3/TLS network protocol analyzer. It identifies TCP
connections on the chosen network interface and attempts to interpret
them as SSLv3/TLS traffic. When it identifies SSLv3/TLS traffic, it
decodes the records and displays them in a textual form to stdout. If
linked with OpenSSL and provided with the appropriate keying material,
it will also decrypt the connections and display the application data
traffic.

ssldump is completely passive and thus allows you to analyze systems
without interfering with them. You can also use it to read stored
traffic collected with tcpdump. 

This release is version 0.9b3. The code quality is considered to be
late Beta. It has seen extensive testing on a number of Unix
platforms including FreeBSD, Solaris, HP/UX and Linux. It uses
autoconf and should be portable to most Unix-based systems.
We consider ssldump 0.9b3 to tbe the best version of ssldump and
recommend users upgrade as soon as possible.

SECURITY NOTE
version 0.9b3 fixes two security problems with protocol decoding.
If you run ssldump in an environment where an attacker might
be able to send you network packets, you should upgrade immediately.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Rescorla | 11 Sep 2002 17:02

ANNOUNCE: ssldump: an SSL protocol analyzer v 0.9b3

ANNOUNCE: ssldump: an SSL protocol analyzer v 0.9b3
Version 0.9b3

http://www.rtfm.com/ssldump/

RTFM, Inc. is pleased to announce the availability of ssldump 0.9b3
ssldump is an SSLv3/TLS network protocol analyzer. It identifies TCP
connections on the chosen network interface and attempts to interpret
them as SSLv3/TLS traffic. When it identifies SSLv3/TLS traffic, it
decodes the records and displays them in a textual form to stdout. If
linked with OpenSSL and provided with the appropriate keying material,
it will also decrypt the connections and display the application data
traffic.

ssldump is completely passive and thus allows you to analyze systems
without interfering with them. You can also use it to read stored
traffic collected with tcpdump. 

This release is version 0.9b3. The code quality is considered to be
late Beta. It has seen extensive testing on a number of Unix
platforms including FreeBSD, Solaris, HP/UX and Linux. It uses
autoconf and should be portable to most Unix-based systems.
We consider ssldump 0.9b3 to tbe the best version of ssldump and
recommend users upgrade as soon as possible.

SECURITY NOTE
version 0.9b3 fixes two security problems with protocol decoding.
If you run ssldump in an environment where an attacker might
be able to send you network packets, you should upgrade immediately.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Rescorla | 11 Sep 2002 18:55

ANNOUNCE: ssldump [correction]

http://www.rtfm.com/ssldump

If you downloaded ssldump from the link on the ssldump web site this
morning, please make sure you got version 0.9b3 and not version
0.9b2. The link on the web site had not been adjusted to point to
0.9b3.

You can check this by checking either the name on the
tarball or 'ssldump -v'.

Here's a direct link:
http://www.rtfm.com/ssldump/ssldump-0.9b3.tar.gz

-Ekr

---
You are currently subscribed to ietf-tls as: ietf-ietf-tls <at> m.gmane.org
To unsubscribe send a blank email to leave-ietf-tls-5391792O <at> lists.certicom.com
Permalink | Reply | 0 comments |
headers
Eric Rescorla | 11 Sep 2002 18:55

ANNOUNCE: ssldump [correction]

http://www.rtfm.com/ssldump

If you downloaded ssldump from the link on the ssldump web site this
morning, please make sure you got version 0.9b3 and not version
0.9b2. The link on the web site had not been adjusted to point to
0.9b3.

You can check this by checking either the name on the
tarball or 'ssldump -v'.

Here's a direct link:
http://www.rtfm.com/ssldump/ssldump-0.9b3.tar.gz

-Ekr
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org
Permalink | Reply | 0 comments |
headers
Trevor Perrin | 11 Sep 2002 20:03
Picon
Favicon

TLS/SRP suggestions


It would be nice if the client could offer the SRP ciphersuites in the 
ClientHello message, but without committing to a username.  This would let a 
client application using TLS to protect SMTP, POP, HTTP, etc., advertise its 
ability to do SRP to a server, but only go ahead and prompt the user to 
enter his username (and password) when the server selects the SRP 
ciphersuite.  On the username/password dialog there might be a checkbox 
saying "always use SRP authentication for this server in the future".  The 
user could select it and from then on, if an active attacker tries to spoof 
the server and denies he supports SRP (ie tries a downgrade attack) the 
client application would warn the user.

This would be a good way of  bootstrapping use of SRP mutual auth within 
legacy protocols, because the fact that two endpoints support SRP would be 
naturally discovered in the course of TLS negotiation.  Otherwise, with the 
current protocol, the client would need some application-specific or 
preconfigured knowledge of when to engage in TLS/SRP and when not to.

As a separate issue, an optimization would be for the client to make a guess 
about which group parameters g,N might be acceptable to the server, and 
proactively send a value of A calculated using these to the server.  The 
server could always refuse to accept this value and send back the values of 
g,N he does accept, forcing the client to generate a new A.  But in cases 
where the client chooses correctly, a round-trip is removed from the 
handshake protocol (from 3 to 2).  The TLS/SRP document could suggest a 
number of default group parameters choices, at different levels of security. 
  Also, a client could remember the group parameters acceptable to a 
particular server, so as to exploit this optimization next time.

So in the current TLS/SRP draft, the client must proactively send a username
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andreas Sterbenz | 11 Sep 2002 20:24
Picon

Re: Leading zeros on encoded big numbers?

David Hopwood wrote:
> 
> I don't think it actually matters whether there are leading zero bytes
> (in this or other cases), as long as integers are always treated as unsigned.
> The encodings of big integers in TLS don't need to be unique; just
> unambiguous.
> 
> Does anyone know if there any TLS (or SSL) implementations that ever
> produce leading zero bytes for big integers?

The SunJSSE implementation uses 2's complement format. I am not aware of 
anybody ever reporting interoperability problems because of this.

Andreas.

---
You are currently subscribed to ietf-tls as: ietf-ietf-tls <at> m.gmane.org
To unsubscribe send a blank email to leave-ietf-tls-5391792O <at> lists.certicom.com
Permalink | Reply | 0 comments |
headers
Eric Rescorla | 11 Sep 2002 20:40

Re: Leading zeros on encoded big numbers?

Andreas Sterbenz <Andreas.Sterbenz <at> sun.com> writes:
> David Hopwood wrote:
> > 
> > I don't think it actually matters whether there are leading zero bytes
> > (in this or other cases), as long as integers are always treated as unsigned.
> > The encodings of big integers in TLS don't need to be unique; just
> > unambiguous.
> > 
> > Does anyone know if there any TLS (or SSL) implementations that ever
> > produce leading zero bytes for big integers?
> 
> The SunJSSE implementation uses 2's complement format. I am not aware of 
> anybody ever reporting interoperability problems because of this.

It's certainly not safe to use leading zeros with RSA signatures,
(which isn't quite the same thing).

I've seen interoperability problems because of that.

-Ekr

--

-- 
[Eric Rescorla                                   ekr <at> rtfm.com]
                http://www.rtfm.com/

---
You are currently subscribed to ietf-tls as: ietf-ietf-tls <at> m.gmane.org
To unsubscribe send a blank email to leave-ietf-tls-5391792O <at> lists.certicom.com
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andreas Sterbenz | 11 Sep 2002 20:55
Picon

Re: Leading zeros on encoded big numbers?

Eric Rescorla wrote:
>>
>>The SunJSSE implementation uses 2's complement format. I am not aware of 
>>anybody ever reporting interoperability problems because of this.
> 
> It's certainly not safe to use leading zeros with RSA signatures,
> (which isn't quite the same thing).
> 
> I've seen interoperability problems because of that.

To be more specific, we use 2's complement for the public key values 
transmitted in the server key exchange (ServerRSAParams and 
ServerDHParams) and client key exchange (ClientDiffieHellmanPublic) only.

I agree that messing with leading zeros on PKCS#1 encrypted blobs would 
cause interoperability problems.

Andreas.

---
You are currently subscribed to ietf-tls as: ietf-ietf-tls <at> m.gmane.org
To unsubscribe send a blank email to leave-ietf-tls-5391792O <at> lists.certicom.com
Permalink | Reply | 0 comments |
headers
Hollenbeck, Scott | 11 Sep 2002 20:44
Picon
Favicon

FW: I-D ACTION:draft-ietf-tls-compression-00.txt

I'm forwarding this to the list since the list manager was having delivery
problems when the announcement was made.  The draft basically captures a
proposal discussed on this mailing list from December 2000; comments
welcome.

-Scott-

-----Original Message-----
From: Internet-Drafts <at> ietf.org [mailto:Internet-Drafts <at> ietf.org]
Sent: Friday, September 06, 2002 7:43 AM
To: IETF-Announce;  <at> loki.ietf.org
Cc: ietf-tls <at> lists.certicom.com
Subject: I-D ACTION:draft-ietf-tls-compression-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Transport Layer Security Working Group of
the IETF.

	Title		: Transport Layer Security Protocol Compression
Methods
	Author(s)	: S. Hollenbeck
	Filename	: draft-ietf-tls-compression-00.txt
	Pages		: 12
	Date		: 2002-9-5
	
The Transport Layer Security (TLS) protocol (RFC 2246) includes
features to negotiate selection of a lossless data compression method
as part of the TLS Handshake Protocol and to then apply the algorithm
associated with the selected method as part of the TLS Record
(Continue reading)

Permalink | Reply | 0 comments |
headers
Win Treese | 11 Sep 2002 22:06
Picon
Favicon

TLS mailing list update


The TLS mailing list should be working again. It is now moderated by me
according to the following guidelines (and in conformance with the
general IETF policy):

1. The main purpose of the moderation is to keep spam off the list while
   making it possible for non-members to post relevant messages.
2. Messages relevant to the TLS mailing list will be approved. If you
   send a message that is approved, you will be allowed to post without
   moderation in the future. (More specifically, the same email address
   will be allowed to post. If you use alternative addresses, let me
   know, or just wait for an extra moderation cycle on the first use of
   a different address.)
3. The TLS list has not, fortunately, had problems with inappropriate
   messages besides spam, so there aren't any new rules about that.
4. If a message is clearly spam (in the view of the moderator), it will
   be deleted without response. If a message is rejected for any other
   reason, the moderator will respond to the sender explaining why.
5. I will endeavor to approve messages fairly quickly, and in general no
   message should be delayed more than 24 hours at most. If I expect to
   be away from email for a long period of time, I will make
   arrangements for one or more other moderators.

In case anyone is interested, the general IETF policy is described at
http://www.ietf.org/IESG/STATEMENTS/mail-submit-policy.txt

In practice, I don't think it will be very different after we get
through the startup phase for the frequent posters.

Win Treese
(Continue reading)

Permalink | Reply | 0 comments |

Gmane