s_server -www -tls1_3: Firefox/Chrome not working

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

s_server -www -tls1_3: Firefox/Chrome not working

Klaus Keppler
Hi,

when I create a TLS-1.3-only "web" server with s_server (from OpenSSL
1.1.1-release), Firefox/Chrome can't access it.
According to all docs I've read so far, the TLS 1.3 implementations both
from Firefox (62.x) and from Chrome (69.x) should be compatible so far.

I created the web server with the following command:

  ./openssl s_server -accept 8444 -tls1_3 \
    -cert sslcert.pem -key sslcert.key \
    -www -state -debug -msg -security_debug_verbose

sslcert.pem/sslcert.key is a self-signed 2048 bit RSA certificate.

When starting without the "-tls1_3" option (or with "-tls1_2"), both
browsers can access that service (an OpenSSL stats page is displayed then).

With "-tls1_3",
- Firefox issues a SSL_ERROR_PROTOCOL_VERSION_ALERT
- Chrome issues a ERR_SSL_VERSION_OR_CIPHER_MISMATCH

Server-side output is the same in both cases, see below for full message.

Connecting to that service using "openssl s_client -connect
localhost:8444" works fine.

There's no proxy, firewall or web filter software involved.
When I open e.g. www.cloudflare.com in a browser, connection is made
using TLS 1.3. So, the browser-side obviously works, I expect the
problem to be on the server-side.

Am I missing something? I can't imagine these products to be incompatible...

Thanks & best regards!

   -Klaus


---cut---
Security callback: Version=TLS 1.3: yes
Security callback: Version=TLS 1.3: yes
SSL_accept:before SSL initialization
read from 0x2335fb0 [0x233c1b3] (5 bytes => 5 (0x5))
0000 - 16 03 01 02 00                                    .....
<<< ??? [length 0005]
    16 03 01 02 00
read from 0x2335fb0 [0x233c1b8] (512 bytes => 512 (0x200))
0000 - 01 00 01 fc 03 03 bb 93-78 7e 86 eb 69 e5 b4 9f
[...]
01f0 - 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
SSL_accept:before SSL initialization
<<< TLS 1.3, Handshake [length 0200], ClientHello
    01 00 01 fc 03 03 bb 93 78 7e 86 eb 69 e5 b4 9f
    c2 28 16 9f 25 27 37 f5 42 5b c9 10 36 09 11 30
    11 7f a5 ec 39 b8 20 15 a8 20 9e 24 0f 78 5d 11
    b0 72 9a b0 4f 74 9b d2 c7 09 64 2d 3d 73 7c 8d
    bd ce 4d f2 de 17 cf 00 1c 13 01 13 03 13 02 c0
    2b c0 2f cc a9 cc a8 c0 2c c0 30 c0 13 c0 14 00
    2f 00 35 00 0a 01 00 01 97 00 17 00 00 ff 01 00
    01 00 00 0a 00 0e 00 0c 00 1d 00 17 00 18 00 19
    01 00 01 01 00 0b 00 02 01 00 00 23 00 00 00 10
    00 0e 00 0c 02 68 32 08 68 74 74 70 2f 31 2e 31
    00 05 00 05 01 00 00 00 00 00 33 00 6b 00 69 00
    1d 00 20 de 3f e9 13 12 8a 84 f4 5b 22 40 ae 3d
    e9 56 04 e8 b4 68 ef 0a 02 fe b7 42 90 ab 26 f1
    95 ff 2d 00 17 00 41 04 41 fd 89 36 89 df 02 3c
    a3 cf 12 8a 27 6f d5 ba 17 29 49 b8 91 6b 6c 95
    e2 7d a8 df fe a5 50 dc 35 0c 3d b5 2a b4 93 70
    17 cd 62 a5 a1 03 7f 32 11 07 04 b3 b0 89 a4 8f
    62 05 9f 69 74 1b c2 99 00 2b 00 09 08 7f 1c 03
    03 03 02 03 01 00 0d 00 18 00 16 04 03 05 03 06
    03 08 04 08 05 08 06 04 01 05 01 06 01 02 03 02
    01 00 2d 00 02 01 01 00 1c 00 02 40 01 00 15 00
    af 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>> ??? [length 0005]
    15 03 03 00 02
write to 0x2335fb0 [0x234a930] (7 bytes => 7 (0x7))
0000 - 15 03 03 00 02 02 46                              ......F
>>> TLS 1.2, Alert [length 0002], fatal protocol_version
    02 46
SSL3 alert write:fatal:protocol version
SSL_accept:error in error
140042894132992:error:14209102:SSL
routines:tls_early_post_process_client_hello:unsupported
protocol:ssl/statem/statem_srvr.c:1655:

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: s_server -www -tls1_3: Firefox/Chrome not working

OpenSSL - User mailing list
On Wed, Sep 12, 2018 at 03:50:17PM +0200, Klaus Keppler wrote:
> Hi,
>
> when I create a TLS-1.3-only "web" server with s_server (from OpenSSL
> 1.1.1-release), Firefox/Chrome can't access it.
> According to all docs I've read so far, the TLS 1.3 implementations both
> from Firefox (62.x) and from Chrome (69.x) should be compatible so far.

You need to check that the browser is implementing the final RFC 8446 version
and not an earlier draft version -- two are incompatible by design
(and OpenSSL 1.1.1 implements the final RFC 8446 version).

IIUC, only Firefox nightly as of approximately today will support the final
RFC 8446 version; I haven't looked into Chrome yet.

-Ben
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: s_server -www -tls1_3: Firefox/Chrome not working

Viktor Dukhovni


> On Sep 12, 2018, at 10:20 AM, Benjamin Kaduk via openssl-users <[hidden email]> wrote:
>
> IIUC, only Firefox nightly as of approximately today will support the final
> RFC 8446 version; I haven't looked into Chrome yet.

From the Firefox TLS 1.3 blog entry:

https://blog.mozilla.org/security/2018/08/13/tls-1-3-published-in-firefox-today/

What Now?

TLS 1.3 is already widely deployed: both Firefox and Chrome have fielded “draft” versions. Firefox 61 is already shipping draft-28, which is essentially the same as the final published version (just with a different version number). We expect to ship the final version in Firefox 63, scheduled for October 2018. Cloudflare, Google, and Facebook are running it on their servers today. Our telemetry shows that around 5% of Firefox connections are TLS 1.3. Cloudflare reports similar numbers, and Facebook reports that an astounding 50+% of their traffic is already TLS 1.3!

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: s_server -www -tls1_3: Firefox/Chrome not working

Viktor Dukhovni


> On Sep 12, 2018, at 10:41 AM, Viktor Dukhovni <[hidden email]> wrote:
>
>> IIUC, only Firefox nightly as of approximately today will support the final
>> RFC 8446 version; I haven't looked into Chrome yet.
>
> From the Firefox TLS 1.3 blog entry:
>
> https://blog.mozilla.org/security/2018/08/13/tls-1-3-published-in-firefox-today/

Similarly, for Chrome the final TLS 1.3 is not out quite yet:

https://www.chromium.org/Home/tls13

Chrome has been shipping a draft version of TLS 1.3 since Chrome 65. In Chrome 70, the final version of TLS 1.3 will be enabled for outgoing connections. (A small percentage may be held back to provide comparison metrics.)

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: s_server -www -tls1_3: Firefox/Chrome not working

Dennis Clarke-2
On 09/12/2018 10:44 AM, Viktor Dukhovni wrote:

>
>
>> On Sep 12, 2018, at 10:41 AM, Viktor Dukhovni <[hidden email]> wrote:
>>
>>> IIUC, only Firefox nightly as of approximately today will support the final
>>> RFC 8446 version; I haven't looked into Chrome yet.
>>
>>  From the Firefox TLS 1.3 blog entry:
>>
>> https://blog.mozilla.org/security/2018/08/13/tls-1-3-published-in-firefox-today/
>
> Similarly, for Chrome the final TLS 1.3 is not out quite yet:
>
> https://www.chromium.org/Home/tls13
>
> Chrome has been shipping a draft version of TLS 1.3 since Chrome 65.
 >In Chrome 70, the final version of TLS 1.3 will be enabled ...

Some Chrome browsers seem to be hitting https://www.tls13.net/ with
versions from Chrome/70.0.3534.4 upwards to Chrome/71.0.3544.0.
The Firefox nightly versions have been fine for a while now. Weeks.
There is no sign of life at all from the Opera people sadly.

Dennis

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: s_server -www -tls1_3: Firefox/Chrome not working

Dennis Clarke-2
In reply to this post by Klaus Keppler
On 09/12/2018 09:50 AM, Klaus Keppler wrote:
> Hi,
>
> when I create a TLS-1.3-only "web" server with s_server (from OpenSSL
> 1.1.1-release), Firefox/Chrome can't access it.

Be sure to use Firefox nightly version 64.0a1 and upwards. Anything less
and you may be getting draft 28 support and NOT actual RFC release
protocol support.

Mozilla/5.0 (X11; Linux x86_64; rv:64.0) Gecko/20100101 Firefox/64.0

That works.

Dennis

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: s_server -www -tls1_3: Firefox/Chrome not working

Angus Robertson - Magenta Systems Ltd
In reply to this post by OpenSSL - User mailing list
> IIUC, only Firefox nightly as of approximately today will support
> the final RFC 8446 version;

Firefox 63.0b5 works OK with OpenSSL 1.1.1, think it came Tuesday.

https://download.mozilla.org/?product=firefox-beta-stub&os=win&lang=en-U
S

> I haven't looked into Chrome yet.

My versions don't work yet, but I might not be on the latest nightly
stuff.

Angus



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: s_server -www -tls1_3: Firefox/Chrome not working

Angus Robertson - Magenta Systems Ltd
In reply to this post by Dennis Clarke-2
> Some Chrome browsers seem to be hitting https://www.tls13.net/ 
> with versions from Chrome/70.0.3534.4 upwards to Chrome/71.0.3544.0

Some of my public web servers are now on yesterday's version, three
TLSv1.3 users today, two with Firefox 63, one with
Chrome/68.0.3440.106+Safari/537.36.  

I seem to be on Chromium Chrome/70.0.3538.9 and TLSv1.3 did not
initially work, had to go to experimental flags to change from draft 28
and final and now it does work.  

Angus


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: s_server -www -tls1_3: Firefox/Chrome not working

Dennis Clarke-2
In reply to this post by Angus Robertson - Magenta Systems Ltd
On 09/12/2018 12:06 PM, Angus Robertson - Magenta Systems Ltd wrote:
>> IIUC, only Firefox nightly as of approximately today will support
>> the final RFC 8446 version;
>
> Firefox 63.0b5 works OK with OpenSSL 1.1.1, think it came Tuesday.
>

Even Firefox/60.0 works.

> https://download.mozilla.org/?product=firefox-beta-stub&os=win&lang=en-U
> S
>
>> I haven't looked into Chrome yet.

Seen in the wild :

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/69.0.3497.42 Safari/537.36

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/69.0.3497.57 Safari/537.36

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/70.0.3538.9 Safari/537.36

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/71.0.3544.0 Safari/537.36


Dennis
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: s_server -www -tls1_3: Firefox/Chrome not working

Juan Isoza
As I understand and check:


https://www.tls13.net accept connexion from final openssl-1.1.1 (RFC8446) but not from openssl-1.1.1 pre8 (draft 28)



https://tls13.crypto.mozilla.org accept connexion from openssl-1.1.1 pre8 (draft 28) but not from final openssl-1.1.1 (RFC8446)


https://www.facebook.com accept connexion from both openssl-1.1.1 pre8 (draft 28) and from final openssl-1.1.1 (RFC8446)

Current public release of chrome and firefox uses draft 28


------

I tested ios 12 GM (published today) on an iPhone and it seem not using TLS 1.3 :-(



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: s_server -www -tls1_3: Firefox/Chrome not working

Dennis Clarke-2
On 09/12/2018 04:46 PM, Juan Isoza wrote:
> As I understand and check:
>
>
> https://www.tls13.net accept connexion from final openssl-1.1.1
> (RFC8446) but not from openssl-1.1.1 pre8 (draft 28)
>

At this point the protocol is published and the OpenSSL 1.1.1 release is
  done. You should not be looking for *draft* anything.

Dennis
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: s_server -www -tls1_3: Firefox/Chrome not working

Klaus Keppler
In reply to this post by Dennis Clarke-2
Hi,

thank you for all your responses.

I've just tested with Firefox Nightly 64.0a1, and both s_server and our
own app (using OpenSSL 1.1.1-release) are working fine.

The Firefox website is quite confusing:

> Firefox 61 is already shipping draft-28, which is essentially the same as the final published version (just with a different version number).

(https://blog.mozilla.org/security/2018/08/13/tls-1-3-published-in-firefox-today/)

This is quite confusing, as it sounds better than it actually is.
(so I've just learned that draft-28 is obviously incompatible with RFC8446)

So thank you for your input, will now continue with OpenSSL 1.1.1.
The rest will be only a matter of time. :D

Best regards

   -Klaus
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: s_server -www -tls1_3: Firefox/Chrome not working

Jakob Bohm-7
On 13/09/2018 09:57, Klaus Keppler wrote:

> Hi,
>
> thank you for all your responses.
>
> I've just tested with Firefox Nightly 64.0a1, and both s_server and our
> own app (using OpenSSL 1.1.1-release) are working fine.
>
> The Firefox website is quite confusing:
>
>> Firefox 61 is already shipping draft-28, which is essentially the same as the final published version (just with a different version number).
> (https://blog.mozilla.org/security/2018/08/13/tls-1-3-published-in-firefox-today/)
>
> This is quite confusing, as it sounds better than it actually is.
> (so I've just learned that draft-28 is obviously incompatible with RFC8446)
>
> So thank you for your input, will now continue with OpenSSL 1.1.1.
> The rest will be only a matter of time. :D
>
> Best regards
>
>     -Klaus
Would it be reasonable for 1.1.1a to add a transitional "bugs" bit (to be
removed again in a few years) to accept the draft version number of final
TLS 1.3, if the protocols are otherwise identical?

This would be similar to the (now historic) bits for known bugs in other
popular clients.  It also seems to be what Facebook has done for their
own servers (according to other posts in this discussion).

Or would it be unproblematic from a real world perspective to just keep
TLS 1.3 non-functional for draft-28 browsers?


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: s_server -www -tls1_3: Firefox/Chrome not working

Dennis Clarke-2
On 09/13/2018 02:13 PM, Jakob Bohm wrote:

> On 13/09/2018 09:57, Klaus Keppler wrote:
>> Hi,
>>
>> thank you for all your responses.
>>
>> I've just tested with Firefox Nightly 64.0a1, and both s_server and our
>> own app (using OpenSSL 1.1.1-release) are working fine.
>>
>> The Firefox website is quite confusing:
>>
>>> Firefox 61 is already shipping draft-28, which is essentially the
>>> same as the final published version (just with a different version
>>> number).
>> (https://blog.mozilla.org/security/2018/08/13/tls-1-3-published-in-firefox-today/)
>>
>>
>> This is quite confusing, as it sounds better than it actually is.
>> (so I've just learned that draft-28 is obviously incompatible with
>> RFC8446)
>>
>> So thank you for your input, will now continue with OpenSSL 1.1.1.
>> The rest will be only a matter of time. :D
>>
>> Best regards
>>
>>     -Klaus
> Would it be reasonable for 1.1.1a to add a transitional "bugs" bit (to be
> removed again in a few years) to accept the draft version number of final
> TLS 1.3, if the protocols are otherwise identical?
>

What would the benefit be?  Allow support for older browsers?  I think
that TLSv1.3 support exists fine in Firefox now and ver 61 is not an ESR
release at all. I am not sure what the benefit would be.  Draft 28 is
much like Draft X for any X less than 28.

> This would be similar to the (now historic) bits for known bugs in other
> popular clients.  It also seems to be what Facebook has done for their
> own servers (according to other posts in this discussion).
>
> Or would it be unproblematic from a real world perspective to just keep
> TLS 1.3 non-functional for draft-28 browsers?

Given that the protocol is published and the browser support exists for
the real protocol then there can not be a raeason to support Draft X.

Dennis


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: s_server -www -tls1_3: Firefox/Chrome not working

OpenSSL - User mailing list
In reply to this post by Jakob Bohm-7
On Thu, Sep 13, 2018 at 08:13:41PM +0200, Jakob Bohm wrote:

> On 13/09/2018 09:57, Klaus Keppler wrote:
> >Hi,
> >
> >thank you for all your responses.
> >
> >I've just tested with Firefox Nightly 64.0a1, and both s_server and our
> >own app (using OpenSSL 1.1.1-release) are working fine.
> >
> >The Firefox website is quite confusing:
> >
> >>Firefox 61 is already shipping draft-28, which is essentially the same as the final published version (just with a different version number).
> >(https://blog.mozilla.org/security/2018/08/13/tls-1-3-published-in-firefox-today/)
> >
> >This is quite confusing, as it sounds better than it actually is.
> >(so I've just learned that draft-28 is obviously incompatible with RFC8446)
> >
> >So thank you for your input, will now continue with OpenSSL 1.1.1.
> >The rest will be only a matter of time. :D
> >
> >Best regards
> >
> >    -Klaus
> Would it be reasonable for 1.1.1a to add a transitional "bugs" bit (to be
> removed again in a few years) to accept the draft version number of final
> TLS 1.3, if the protocols are otherwise identical?
>
> This would be similar to the (now historic) bits for known bugs in other
> popular clients.  It also seems to be what Facebook has done for their
> own servers (according to other posts in this discussion).
>
> Or would it be unproblematic from a real world perspective to just keep
> TLS 1.3 non-functional for draft-28 browsers?

It would be unproblematic.  Such browsers will use TLS 1.2 just fine, and
are going to be auto-updating to a version capable of official TLS 1.3
very soon anyway.

-Ben
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: s_server -www -tls1_3: Firefox/Chrome not working

OpenSSL - User mailing list
Much work for little gain and purpose.

You can mix drafts, but mixing the draft and the official version is hard, there's too many semantic changes (e.g., around fallback vs no-fallback-protection).

 

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: s_server -www -tls1_3: Firefox/Chrome not working

Jakob Bohm-7
On 13/09/2018 21:47, Salz, Rich via openssl-users wrote:
> Much work for little gain and purpose.
>
> You can mix drafts, but mixing the draft and the official version is hard, there's too many semantic changes (e.g., around fallback vs no-fallback-protection).
Ok, from what others had said, the only change between draft-28 and
final was supposedly the version number.  Given all the talk of
testing of the protocol design, it would seem out of character for
the WG to have mechanisms that were disabled in all the drafts and
thus untested.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: s_server -www -tls1_3: Firefox/Chrome not working

Kurt Roeckx
In reply to this post by Jakob Bohm-7
On Thu, Sep 13, 2018 at 08:13:41PM +0200, Jakob Bohm wrote:

> On 13/09/2018 09:57, Klaus Keppler wrote:
> > Hi,
> >
> > thank you for all your responses.
> >
> > I've just tested with Firefox Nightly 64.0a1, and both s_server and our
> > own app (using OpenSSL 1.1.1-release) are working fine.
> >
> > The Firefox website is quite confusing:
> >
> > > Firefox 61 is already shipping draft-28, which is essentially the same as the final published version (just with a different version number).
> > (https://blog.mozilla.org/security/2018/08/13/tls-1-3-published-in-firefox-today/)
> >
> > This is quite confusing, as it sounds better than it actually is.
> > (so I've just learned that draft-28 is obviously incompatible with RFC8446)
> >
> > So thank you for your input, will now continue with OpenSSL 1.1.1.
> > The rest will be only a matter of time. :D
> >
> > Best regards
> >
> >     -Klaus
> Would it be reasonable for 1.1.1a to add a transitional "bugs" bit (to be
> removed again in a few years) to accept the draft version number of final
> TLS 1.3, if the protocols are otherwise identical?

Draft versions really should die as soon as possible. If we ever put
it in a released version, it will still be in use in 10 years,
which really isn't something we want.

On the other hand, in a few weeks browsers will stop using those
draft versions, so I really don't see the point.


Kurt

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: s_server -www -tls1_3: Firefox/Chrome not working

Jakob Bohm-7
On 15/09/2018 10:46, Kurt Roeckx wrote:

> On Thu, Sep 13, 2018 at 08:13:41PM +0200, Jakob Bohm wrote:
>> On 13/09/2018 09:57, Klaus Keppler wrote:
>>> Hi,
>>>
>>> thank you for all your responses.
>>>
>>> I've just tested with Firefox Nightly 64.0a1, and both s_server and our
>>> own app (using OpenSSL 1.1.1-release) are working fine.
>>>
>>> The Firefox website is quite confusing:
>>>
>>>> Firefox 61 is already shipping draft-28, which is essentially the same as the final published version (just with a different version number).
>>> (https://blog.mozilla.org/security/2018/08/13/tls-1-3-published-in-firefox-today/)
>>>
>>> This is quite confusing, as it sounds better than it actually is.
>>> (so I've just learned that draft-28 is obviously incompatible with RFC8446)
>>>
>>> So thank you for your input, will now continue with OpenSSL 1.1.1.
>>> The rest will be only a matter of time. :D
>>>
>>> Best regards
>>>
>>>      -Klaus
>> Would it be reasonable for 1.1.1a to add a transitional "bugs" bit (to be
>> removed again in a few years) to accept the draft version number of final
>> TLS 1.3, if the protocols are otherwise identical?
> Draft versions really should die as soon as possible. If we ever put
> it in a released version, it will still be in use in 10 years,
> which really isn't something we want.
>
> On the other hand, in a few weeks browsers will stop using those
> draft versions, so I really don't see the point.
My point was about the likelihood of last-draft browsers lingering
on in the real world for some time (like 1 to 3 years) after the
TLS1.3-final browser versions ship.  The inspiration was the report
that facebook had done this on their own servers, presumably based
on their massive metrics of real world browsers.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: s_server -www -tls1_3: Firefox/Chrome not working

OpenSSL - User mailing list
>    My point was about the likelihood of last-draft browsers lingering
    on in the real world for some time (like 1 to 3 years) after the
    TLS1.3-final browser versions ship.

I do not think this is a concern.  Chrome and FF auto-update and get almost full coverage within a month or two, for example.  Edge hasn't shipped TLS 1.3 yet. Safari encourages auto-update.  That's most of the browser market.



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
12