headers
Peter Gutmann | 4 Nov 2003 12:49
Picon
Picon
Picon
Favicon

TLS 1.1 question and comments

First the question: Is anyone running a TLS 1.1 server that I can bounce some
messages off?

Next the comments (maybe a bit late, but I'd been working from a rather old
draft until now):

Section 6.2.3.2, the padding text is now explicit about checking the padding,
which older versions weren't.  This level of checking is going to break
implementations that don't use proper PKCS #5 padding (there's at least one I
know of that simply skips ahead n bytes, sending the client whatever was in
the server's memory at that point).  The fact that this behaviour has survived
in implementations indicates that currently compliance with this may be
limited.  It might be worth either adding a compatibility note or only making
the checking mandatory for TLS 1.1.

Section 7.4.7.1, typo "to to check".

Appendix E, there are still servers out there that break if sent a TLS 1.0
hello (they continue OK after falling back to SSL, but then bail out at the
end of the handshake presumably because they hardcoded some SSL ID into a MAC
instead of the supplied TLS one).  Given this behaviour, it's likely that the
same thing will happen with TLS 1.1, so perhaps a compatibility note would
help implementors, e.g. "may or may not respond" rather than "will respond"
:-).

Appendix F.5, the general SYN-flooding stuff is already well-known, the real
SSL-specific threat is an attacker using a pile of zombies to spray bogus
client keyex's at a server forcing the server to perform an RSA private-key op
to detect the problem.  As of TLS 1.1 this is even worse since it interacts
badly with the requirement in section 7.4.7.1 that the server continue the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Gutmann | 5 Nov 2003 02:06
Picon
Picon
Picon
Favicon

Re: TLS 1.1 question and comments

daw <at> taverner.cs.berkeley.edu (David Wagner) writes:
>Peter Gutmann wrote:
>>Section 6.2.3.2, the padding text is now explicit about checking the padding,
>>which older versions weren't.  [...]
>
>Is it safe to skip checking the padding?  I'm wondering about the possibility
>of Vaudenay-style attacks.  Does anyone know whether this is ought to be a
>concern?

I believe that was the motivation for making the padding-check explicit.  The
problem is that this can break compatibility with existing implementations,
which is why it might be better to make it a new-for-1.1 feature, along with
other stuff like explicit IVs.

Peter.
Permalink | Reply | 0 comments |
headers
David Wagner | 4 Nov 2003 20:42
Picon

Re: TLS 1.1 question and comments

Peter Gutmann wrote:
>Section 6.2.3.2, the padding text is now explicit about checking the padding,
>which older versions weren't.  [...]

Is it safe to skip checking the padding?  I'm wondering about
the possibility of Vaudenay-style attacks.  Does anyone know whether
this is ought to be a concern?
Permalink | Reply | 0 comments |
headers
Bodo Moeller | 5 Nov 2003 13:42
Picon
Favicon

Re: TLS 1.1 question and comments

On Tue, Nov 04, 2003 at 07:42:20PM +0000, David Wagner wrote:
> Peter Gutmann wrote:

>> Section 6.2.3.2, the padding text is now explicit about checking the padding,
>> which older versions weren't.  [...]

> Is it safe to skip checking the padding?  I'm wondering about
> the possibility of Vaudenay-style attacks.  Does anyone know whether
> this is ought to be a concern?

There are (at least) two problems if padding is not checked:

1.  Note that unlike SSL 3.0, TLS allows up to 256 bytes of padding,
    i.e. you can use more than the block size if desired.  With
    standard padding for a cipher block size of 8 bytes, say, you hide
    only three bits of the plaintext length; with TLS padding, you can
    hide eight bits of the plaintext length.

    If padding is not checked, then the plaintext length is not
    properly hidden: if an adversary randomly modifies a ciphertext
    block in transit and this does not cause problems to the TLS
    connection, then it can be deduced that this bytes lies entirely
    within the padding.

    (Say the adversary modifies the last-but-one ciphertext block, but
    doesn't touch its last byte.  During CBC decryption, this affects
    the final two plaintext blocks, but the byte indicating the
    padding length won't be changed.  So if at least two blocks of
    padding have been used, the TLS connection will continue.)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Gutmann | 5 Nov 2003 15:58
Picon
Picon
Picon
Favicon

Re: TLS 1.1 question and comments

Bodo Moeller <moeller <at> cdc.informatik.tu-darmstadt.de> writes:

>[Nice summary snipped]
>
>Recommendation for 2b: disable SSL 3.0, which handles padding approximately
>as described there (the difference is that SSL 3.0 does not subtract one from
>the padding length, i.e. the final byte must be 08, not 07).

This is really a problem of security vs.interoperability.  Most SSL
implementations that I checked [0] simply dropped a count byte at the end of
the padded range and left it at that, with no attempt at PKCS #5 padding (or
to erase what was in the server's memory before it assembled the packet in the
same space, so you get a nice data leak from the server).  If you switch to
TLS, you get proper (well, almost) PKCS #5 padding in most, but not all, cases
(carryovers from SSL I guess).  So enabling PKCS #5 checking for SSL is a non-
starter, and enabling it for TLS 1.0 is going to be risky.  I realise that I
should probably do it, but the last time I tried it there were adverse user
reactions... what do other implementations do?  Is anyone doing strict
checking for PKCS #5-type padding and rejecting connections if it's not
present?  If so, how many user complaints have you had?

Oh, one other data point for padding lengths: I've never found an
implementation that pads to more than one block size.

Peter.

[0] Insert selected mini-rants about (a) the akamai-isation of the world, 
    (c) doesn't *anyone* have certs that match their FQDN any more?, and (d)
    what happened to (b)?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hugo Krawczyk | 6 Nov 2003 02:00
Picon

Re: TLS 1.1 question and comments


On Thu, 6 Nov 2003, Peter Gutmann wrote:

[snip...]

>
> [0] Insert selected mini-rants about (a) the akamai-isation of the world,
>   (c) doesn't *anyone* have certs that match their FQDN any more?, and (d)
>   what happened to (b)?
>
>

(e) all this trouble with the insecurity effects of ciphertext padding
stems from the wrong order of encryption and authentication in SSL/TLS.
Not that anyone is going to change that in these protocols, but just
wanted to take the opportunity to remind those that work on new protocols
to stick to the encrypt-then-authenticate (provably) secure order.
Permalink | Reply | 0 comments |
headers
Bodo Moeller | 5 Nov 2003 20:35
Picon
Favicon

Re: TLS 1.1 question and comments

On Thu, Nov 06, 2003 at 03:58:04AM +1300, Peter Gutmann wrote:

> This is really a problem of security vs.interoperability.  Most SSL
> implementations that I checked [0] simply dropped a count byte at the end of
> the padded range and left it at that, with no attempt at PKCS #5 padding (or
> to erase what was in the server's memory before it assembled the packet in the
> same space, so you get a nice data leak from the server).

The SSL 3.0 specification does not say anything about PKCS #5 padding
or otherwise make any really specific recommendations about how to
pad.  While using PKCS #5 padding would be a reasonable choice for
senders, there is nothing in the specification that would lead you to
expect interoperability with other implementations if you insist on
PKCS #5 padding in CBC encrypted data that you receive:

4.7 Cryptographic attributes

   [...]

   In block cipher encryption, every block of plaintext encrypts to a
   block of ciphertext.  Because it is unlikely that the plaintext
   (whatever data is to be sent) will break neatly into the necessary
   block size (usually 64 bits), it is necessary to pad out the end of
   short blocks with some regular pattern, usually all zeroes.

   [...]

5.2.3.2 CBC block cipher

   [...]
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bodo Moeller | 6 Nov 2003 13:34
Picon
Favicon

Re: TLS 1.1 question and comments

On Wed, Nov 05, 2003 at 08:35:23PM +0100, Bodo Moeller wrote:

>> TLS, you get proper (well, almost) PKCS #5 padding in most, but not all, cases
>> (carryovers from SSL I guess).  So enabling PKCS #5 checking for SSL is a non-
>> starter, and enabling it for TLS 1.0 is going to be risky.  I realise that I
>> should probably do it, but the last time I tried it there were adverse user
>> reactions... what do other implementations do?  Is anyone doing strict
>> checking for PKCS #5-type padding and rejecting connections if it's not
>> present?  If so, how many user complaints have you had?

> OpenSSL does check TLS 1.0 padding, but there is a compatibility
> option SSL_OP_TLS_BLOCK_PADDING_BUG.

This option does not tolerate arbitrary padding, though, it just
accepts one very specific additional padding style.  I am not aware of
user complaints concerning incompatibility related to TLS 1.0 CBC
padding.
Permalink | Reply | 0 comments |
headers
Peter Gutmann | 8 Nov 2003 05:43
Picon
Picon
Picon
Favicon

Re: TLS 1.1 question and comments

Bodo Moeller <moeller <at> cdc.informatik.tu-darmstadt.de> writes:

>> OpenSSL does check TLS 1.0 padding, but there is a compatibility
>> option SSL_OP_TLS_BLOCK_PADDING_BUG.
>
>This option does not tolerate arbitrary padding, though, it just accepts one
>very specific additional padding style.  I am not aware of user complaints
>concerning incompatibility related to TLS 1.0 CBC padding.

I've been trying to find somewhere that has problems with TLS (as opposed to
SSL) padding, but the only two servers I could find fall back to SSL after the
TLS hello and so were really SSL servers.  Unfortunately I never recorded the
URLs of problem servers in the past because may of them tend to be rather
ephemeral (they're running a new server version every time you check back) so
that didn't help either.  I guess I'll re-enable it for TLS 1.0 (currently
it's only enabled for 1.1) and see if people complain.

Actually while I'm at it I'll repeat a previous unanswered question: Does
anyone have a TLS 1.1 server that I can bounce some test messages off?  Surely
I'm not the first people to have implemented this.

Peter.
Permalink | Reply | 0 comments |
headers
Jostein Tveit | 12 Nov 2003 13:35
Picon
Picon
Favicon

Re: TLS 1.1 question and comments

pgut001 <at> cs.auckland.ac.nz (Peter Gutmann) writes:

> Appendix F.5, the general SYN-flooding stuff is already well-known, the real
> SSL-specific threat is an attacker using a pile of zombies to spray bogus
> client keyex's at a server forcing the server to perform an RSA private-key op
> to detect the problem. 

I wonder if anyone of you have tried this in practice, and have any results
of how fast a server will stop responding to legitimate requests compared
to standard SYN-flooding.

I currently do a master thesis on security vulnerabilities in SSL/TLS
implementations and this looks like an interesting (and rather easy) thing
to test in practice.

Thanks in advance!

--

-- 
Jostein Tveit (Jostein.Tveit <at> idi.ntnu.no)
Permalink | Reply | 0 comments |

Gmane