Re: [openssl-dev] Calculating DTLS payload MTU

2016-10-05 Thread Matt Caswell
On 05/10/16 22:51, David Woodhouse wrote: > On Wed, 2016-10-05 at 21:29 +0100, Matt Caswell wrote: >> Hwell its not constant even by cipher. It depends on the >> transport (IPv6 has a bigger overhead than IPv4). > > That is included in d1->link_mtu (DTLS_set_link_mtu()) but is not >

Re: [openssl-dev] Calculating DTLS payload MTU

2016-10-05 Thread David Woodhouse
On Wed, 2016-10-05 at 20:46 +0100, Matt Caswell wrote: > > Or even 1.1.1! Why don't you pull this together into a github PR? https://github.com/openssl/openssl/pull/1666 Not complete, but good enough for you to heckle at the approach, and it'll be a whole lot simpler for someone with more clue

Re: [openssl-dev] [openssl.org #4697] Bug in 1.1.0 (lost compatibility with previous releases)

2016-10-05 Thread David Woodhouse
On Wed, 2016-10-05 at 09:08 +, Salz, Rich via RT wrote: > I think you are reading too much into Viktor's words.  From my > perspective he was proposing a work-around, nothing more. OK, that makes sense. > Yeah, what we did is sub-optimal.  Not the first time, won't be the > last :) :) --

[openssl-dev] [openssl.org #4698] PEM parsing incorrect; whitespace in PEM crashes parser

2016-10-05 Thread Timothe Litt via RT
PEM consists of base64 inside a header and trailer line. OpenSSL crashes with embedded newlines. This was mentioned to me by the OpenXPKI project. See RFC 7468 section 2: Data before the encapsulation boundaries are permitted, and parsers MUST NOT malfunction when processing such data.

Re: [openssl-dev] [openssl.org #4697] Bug in 1.1.0 (lost compatibility with previous releases)

2016-10-05 Thread David Woodhouse
On Wed, 2016-10-05 at 07:17 +, Viktor Dukhovni wrote: > On Wed, Oct 05, 2016 at 07:05:06AM +, Sergey G Brazhnikov via RT wrote: > > > > > Just figured out that files encrypted with OpenSSL 1.1.0-stable can not be > > decrypted with previous releases and vice versa. > > Tested aes256,

Re: [openssl-dev] [openssl.org #4698] PEM parsing incorrect; whitespace in PEM crashes parser

2016-10-05 Thread Salz, Rich via RT
Well, it is a SHOULD not a MUST. But point taken it could be (much) better :) -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4698 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe:

[openssl-dev] [openssl.org #4697] Bug in 1.1.0 (lost compatibility with previous releases)

2016-10-05 Thread Stephen Henson via RT
On Wed Oct 05 07:05:06 2016, sgbrazhni...@gmail.com wrote: > Hi, guys. > > Just figured out that files encrypted with OpenSSL 1.1.0-stable can not be > decrypted with previous releases and vice versa. > Tested aes256, cast5-cfb, camellia128 on 1.1.0-stable, 1.0.2-stable and > 0.9.8(cast5-cfb only)

Re: [openssl-dev] [openssl.org #4698] PEM parsing incorrect; whitespace in PEM crashes parser

2016-10-05 Thread Timothe Litt via RT
On 05-Oct-16 07:52, Salz, Rich via RT wrote: > Well, it is a SHOULD not a MUST. But point taken it could be (much) better :) > > It's an important SHOULD. Whitespace introduction happens in the wild. This is the quote from the OpenXPKI folks: > I just saw this today at a customer install that

Re: [openssl-dev] Calculating DTLS payload MTU

2016-10-05 Thread David Woodhouse
On Wed, 2016-10-05 at 21:29 +0100, Matt Caswell wrote: > Hwell its not constant even by cipher. It depends on the > transport (IPv6 has a bigger overhead than IPv4). That is included in d1->link_mtu (DTLS_set_link_mtu()) but is not included in d1->mtu (SSL_set_mtu()). Even when we let

Re: [openssl-dev] [openssl.org #4697] Bug in 1.1.0 (lost compatibility with previous releases)

2016-10-05 Thread Salz, Rich
> And the *only* justification for the fact that bug continues to exist — and in > fact we introduced a *new* bug in OpenSSL 1.1 instead of fixing it — is for > backward compatibility with older releases. > > So how can we be so sanguine about the above failure report? Because backward

Re: [openssl-dev] [openssl.org #4697] Bug in 1.1.0 (lost compatibility with previous releases)

2016-10-05 Thread David Woodhouse
On Wed, 2016-10-05 at 08:03 +, Salz, Rich wrote: > > > And the *only* justification for the fact that bug continues to exist — and > > in > > fact we introduced a *new* bug in OpenSSL 1.1 instead of fixing it — is for > > backward compatibility with older releases. > > > > So how can we be

[openssl-dev] [openssl.org #4697] Bug in 1.1.0 (lost compatibility with previous releases)

2016-10-05 Thread Sergey G Brazhnikov via RT
Hi, guys. Just figured out that files encrypted with OpenSSL 1.1.0-stable can not be decrypted with previous releases and vice versa. Tested aes256, cast5-cfb, camellia128 on 1.1.0-stable, 1.0.2-stable and 0.9.8(cast5-cfb only) All built without errors, passed all tests. Configuration VC-WIN32,

Re: [openssl-dev] [openssl.org #4697] Bug in 1.1.0 (lost compatibility with previous releases)

2016-10-05 Thread Viktor Dukhovni
On Wed, Oct 05, 2016 at 07:05:06AM +, Sergey G Brazhnikov via RT wrote: > Just figured out that files encrypted with OpenSSL 1.1.0-stable can not be > decrypted with previous releases and vice versa. > Tested aes256, cast5-cfb, camellia128 on 1.1.0-stable, 1.0.2-stable and > 0.9.8(cast5-cfb

Re: [openssl-dev] [openssl.org #4697] Bug in 1.1.0 (lost compatibility with previous releases)

2016-10-05 Thread Salz, Rich via RT
I think you are reading too much into Viktor's words. From my perspective he was proposing a work-around, nothing more. Yeah, what we did is sub-optimal. Not the first time, won't be the last :) -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4697 Please log in as guest with

Re: [openssl-dev] [openssl.org #4697] Bug in 1.1.0 (lost compatibility with previous releases)

2016-10-05 Thread David Woodhouse
On Wed, 2016-10-05 at 07:05 +, Sergey G Brazhnikov via RT wrote: > > Just figured out that files encrypted with OpenSSL 1.1.0-stable can not be > decrypted with previous releases and vice versa. > Tested aes256, cast5-cfb, camellia128 on 1.1.0-stable, 1.0.2-stable and > 0.9.8(cast5-cfb only)

Re: [openssl-dev] [openssl.org #4697] Bug in 1.1.0 (lost compatibility with previous releases)

2016-10-05 Thread David Woodhouse via RT
On Wed, 2016-10-05 at 07:05 +, Sergey G Brazhnikov via RT wrote: > > Just figured out that files encrypted with OpenSSL 1.1.0-stable can not be > decrypted with previous releases and vice versa. > Tested aes256, cast5-cfb, camellia128 on 1.1.0-stable, 1.0.2-stable and > 0.9.8(cast5-cfb only)

Re: [openssl-dev] Calculating DTLS payload MTU

2016-10-05 Thread Matt Caswell
On 05/10/16 00:39, David Woodhouse wrote: > I have the link MTU (typically 1500 bytes), and a DTLS session is > established. > > I call DTLS_set_link_mtu() to set the link MTU. > > I need to know the DTLS data MTU — the maximum payload size, which > depends on the cipher in use. > > For

Re: [openssl-dev] Calculating DTLS payload MTU

2016-10-05 Thread David Woodhouse
On Wed, 2016-10-05 at 10:04 +0100, Matt Caswell wrote: > > > For example for AES-128-GCM-SHA256 we'd start with 1500 and subtract: > >  - 20 bytes for a Legacy IP header. > >  - 8 bytes for UDP header. > >  - 13 bytes for DTLS header > >  - 16 bytes for the hash > >  - 8 bytes for nonce > > > >

Re: [openssl-dev] [openssl.org #4697] Bug in 1.1.0 (lost compatibility with previous releases)

2016-10-05 Thread Sergey G Brazhnikov via RT
Yes, Steve, you're right! Thank you. I'm sorry for imprecise wording. Sergey. 2016-10-05 16:24 GMT+05:00 Stephen Henson via RT : > On Wed Oct 05 07:05:06 2016, sgbrazhni...@gmail.com wrote: > > Hi, guys. > > > > Just figured out that files encrypted with OpenSSL 1.1.0-stable

Re: [openssl-dev] [openssl.org #4696] Resolved: BUG: openssl1.0.2j Solaris-Sparc : ../util/shlib_wrap.sh ./bad_dtls_test - core dump

2016-10-05 Thread Llewelyn Thomas via RT
Confirmed - thanks for the reply! From: Rich Salz via RT Sent: 05 October 2016 08:09:49 To: Llewelyn Thomas Subject: [openssl.org #4696] Resolved: BUG: openssl1.0.2j Solaris-Sparc : ../util/shlib_wrap.sh ./bad_dtls_test - core dump According

[openssl-dev] [openssl.org #4698] PEM parsing incorrect; whitespace in PEM crashes parser

2016-10-05 Thread Richard Levitte via RT
To be noted, there's more in section 2: Most extant parsers ignore blanks at the ends of lines; blanks at the beginnings of lines or in the middle of the base64-encoded data are far less compatible. These observations are codified in Figure 1. The most lax parser implementations are

Re: [openssl-dev] [openssl.org #4698] PEM parsing incorrect; whitespace in PEM crashes parser

2016-10-05 Thread Timothe Litt via RT
On 05-Oct-16 08:56, Richard Levitte via RT wrote: > To be noted, there's more in section 2: > >Most extant parsers ignore blanks at the ends of lines; blanks at the >beginnings of lines or in the middle of the base64-encoded data are >far less compatible. These observations are

Re: [openssl-dev] [openssl.org #4698] PEM parsing incorrect; whitespace in PEM crashes parser

2016-10-05 Thread Kaduk, Ben via RT
On 10/05/2016 07:56 AM, Richard Levitte via RT wrote: > To be noted, there's more in section 2: > >Most extant parsers ignore blanks at the ends of lines; blanks at the >beginnings of lines or in the middle of the base64-encoded data are >far less compatible. These observations are

Re: [openssl-dev] Calculating DTLS payload MTU

2016-10-05 Thread David Woodhouse
On Wed, 2016-10-05 at 14:40 +0100, David Woodhouse wrote: > How's this for a start... Now I think I have it right for CCM too, although having to use strstr() for that makes me *very* sad. Next up, Chacha20-Poly1305... and then maybe I can stop worrying about new modes and ciphersuites because

Re: [openssl-dev] [openssl.org #4698] PEM parsing incorrect; whitespace in PEM crashes parser

2016-10-05 Thread Timothe Litt via RT
One more reference: https://tools.ietf.org/html/rfc4648#section-3.3 describes the considerations for 'non-base64 characters'. Short form: MIME requires that they be ignored. 7468 says SHOULD. 4648 says 'reject, unless the referencing spec says otherwise' (which 7468 does.) I wrote previously

Re: [openssl-dev] Calculating DTLS payload MTU

2016-10-05 Thread Matt Caswell
On 05/10/16 15:37, David Woodhouse wrote: > DTLS_set_link_mtu(vpninfo->dtls_ssl, mtu); > > /* We already set the link MTU, but hopefully by the time we >* finish it, this function will be better at working out the >* actual tunnel MTU than OpenSSL is. So do that

Re: [openssl-dev] Calculating DTLS payload MTU

2016-10-05 Thread Matt Caswell
On 05/10/16 15:37, David Woodhouse wrote: > On Wed, 2016-10-05 at 14:40 +0100, David Woodhouse wrote: >> How's this for a start... > > Now I think I have it right for CCM too, although having to use > strstr() for that makes me *very* sad. Next up, Chacha20-Poly1305... > and then maybe I can

Re: [openssl-dev] Calculating DTLS payload MTU

2016-10-05 Thread David Woodhouse
> > > On 05/10/16 15:37, David Woodhouse wrote: >> On Wed, 2016-10-05 at 14:40 +0100, David Woodhouse wrote: >>> How's this for a start... >> >> Now I think I have it right for CCM too, although having to use >> strstr() for that makes me *very* sad. Next up, Chacha20-Poly1305... >> and then

Re: [openssl-dev] Calculating DTLS payload MTU

2016-10-05 Thread David Woodhouse
On Wed, 2016-10-05 at 21:31 +0100, Matt Caswell wrote: > > > On 05/10/16 15:37, David Woodhouse wrote: > >   DTLS_set_link_mtu(vpninfo->dtls_ssl, mtu); > >  > >   /* We already set the link MTU, but hopefully by the time we > >    * finish it, this function will be better at working