Re: [TLS] Deprecating SSLv3

Hubert Kario <> Mon, 24 November 2014 17:43 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C42541A8735 for <>; Mon, 24 Nov 2014 09:43:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id K40cqgoQdPIX for <>; Mon, 24 Nov 2014 09:43:16 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5259B1A19EF for <>; Mon, 24 Nov 2014 09:43:16 -0800 (PST)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id sAOHhFoh027992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 24 Nov 2014 12:43:15 -0500
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id sAOHhEGc014238 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 24 Nov 2014 12:43:15 -0500
From: Hubert Kario <>
Date: Mon, 24 Nov 2014 18:43:13 +0100
Message-ID: <>
User-Agent: KMail/4.14.2 (Linux/3.16.7-200.fc20.x86_64; KDE/4.14.2; x86_64; ; )
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
X-Scanned-By: MIMEDefang 2.68 on
Subject: Re: [TLS] Deprecating SSLv3
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 24 Nov 2014 17:43:17 -0000

On Monday 24 November 2014 18:06:22 Martin Rex wrote:
> Hubert Kario wrote:
> > Anyway, you should file a complaint to the manufacturer that it haven't
> > addressed the POODLE vulnerability in their product (or that it doesn't
> > implement advertised protocols properly).
> Poodle is a *PURE* Web-Browser and client problem.
> Servers are not vulnerable to Poodle, and this site *REQUIRES*
> TLS client certs for authentication.
> Disabling SSLv3 on servers is only a practical mitigation against
> the stupid "downgrade dance" that so many browsers perform.
> It's difficult for me to understand how someone could implement
> the downgrade dance and *NOT* provide a switch to turn it off after
> addressing the rfc5746 tls renegotiation issue.

To exploit POODLE you need fallback dance *or* support just SSLv3. It's not 
limited to web browsers (and there are some clients that do fallback and are 
not browsers, e.g. curl).

Also, are you saying that an *automated* system won't retry on connection 

We're talking about average of 128 failed requests per byte decrypted, even if 
we fail just every first connection on a system that queries remote server 
every 5 minutes 24/7 that will require just a month to decrypt 16 byte 
password/authentication string. There have been far more dedicated and longer 
attacks in the wild.

SSLv3 has known security problems, more issues may be discovered in the 
future... or not (as the researchers may decide that it was thus completely 
broken and as such not worth investigating further). So while use of 
certificates may mitigate this problem, we may not ever know if it mitigates 
all problems SSLv3 has. For example, issues like 3-shake won't be fixed in 
SSLv3. In my opinion, continued use of it for security-critical applications 
qualifies for gross negligence.

Do we really need the repeat of the MD5 signatures story or can we learn on 
our own (as in industry) mistakes?
Hubert Kario