Re: [openssl-users] s_server -www -tls1_3: Firefox/Chrome not working
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
Re: [openssl-users] s_server -www -tls1_3: Firefox/Chrome not working
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
Re: [openssl-users] s_server -www -tls1_3: Firefox/Chrome not working
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
Re: [openssl-users] s_server -www -tls1_3: Firefox/Chrome not working
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
Re: [openssl-users] s_server -www -tls1_3: Firefox/Chrome not working
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
Re: [openssl-users] Checksum for openssl-1.0.2p download
On 13/09/2018 03:24, Michael Wojcik wrote: From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Jakob Bohm Sent: Wednesday, September 12, 2018 17:18 Testing your OpenSSL download with the HTTPS security bites its own tail, especially if your download tool uses an (older) version of OpenSSL to check the connection. And as I noted in my previous email, the HTTPS PKI is rubbish. Historically there have been numerous successful attacks on it, even in modes that do not involve user intervention. It's better than nothing, but checking the PGP signature is defense in depth that does not rely solely on the integrity of the HTTPS PKI. But unless you have an established personal list of GPG/PGP keys you have checked against their holders in person yourself, checking the HTTPS certificate of the OpenSSL.org web server is pretty much all you can do to distinguish between a genuine and a fake first time OpenSSL download (signatures on later downloads can be compared to previous downloadsfor some degree of signature consistency). There are plenty of other channels that can be used to validate the PGP public key used to confirm the signature of the OpenSSL tarball. None of them are secure in themselves, but by using multiple channels, the defender greatly increases the attacker's work factor and risk of discovery. That's the whole point of defense in depth. It's not hard to learn how to install an OpenPGP implementation (most likely gpg) and use it to verify a detached signature. There are many tutorials available online. I don't think a lack of experience with PGP or gpg is a valid excuse for not validating the signature. Of cause some real knowledge is needed to not use the OpenSSL source code incorrectly, unless you are merely compiling other peoples software exactly as instructed. Yes. And this is a much more likely source of problems than a counterfeit OpenSSL distribution. To make it clear, I am very experienced and do in fact check the gpg signature if possible. I was trying to give good advice to the OP based on my experience checking the only ways that the OpenSSL foundation provides. The OpenPGP/GPG key servers that you suggested, by design, accept any made up key identity and thus provide no indication of validity, so just downloading the key from there is a non-solution to the problem of bootstrapping trust in someones first OpenSSL download. To my knowledge the only ways to check that the .asc file was signed with an authorized release key are: A) Trusting that the HTTPS connection to the download server is uncompromised, essentially treating at least the first such signature as a glorified .sha256 file. B) Checking doc/fingerprints.txt in the previous tarball and hoping the OpenSSL foundation double checks the correctness of that file before signing a new tarball. C) Using the text (BUT NOT THE INSECURE LINKS) on https://www.openssl.org/community/omc.html But this lists some unauthorized keys, and also relies on that same HTTPS certificate. 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
[openssl-users] DTLS-over-UDP client example
Hello !
I'm completely new to openssl, but really need to implement simple application
which will use DTLS over UDP.
Unfortunelly, it seems that all examples which I can find, correctly implement
DTLS server, but not implement DTLS client side.
For example, this one:
https://github.com/nplab/DTLS-Examples/blob/master/src/dtls_udp_echo.c
implement both client and server, but all connection from client to server have
no encoding:
SSL_CIPHER_get_name(SSL_get_current_cipher(ssl)) returns "NULL-SHA256";
It's because client side sets SSL_CTX_set_cipher_list(ctx, "eNULL:!MD5");
If I try to connect to the dtls_udp_echo application in server mode using
openssl s_client, it connects successfully and with encoding enabled
("AES256-SHA").
If I change client side SSL_CTX_set_cipher_list to "ALL", or "AES256:SHA" -
SSL_connect() on client hangs forever.
I think, the reason is that server side require cookie exchange, and clients
side doesn't implement it.
At least, if I connect using openssl s_client, on server side both
verify_cookie and generate_cookie was called.
If I use example client, only generate_cookie was called.
Client just hangs forever, sending packets to server every few seconds until
timeout expired (~8 minutes) and return
SSL_connect: Resource temporarily unavailable
error:1413C138:SSL routines:dtls1_check_timeout_num:read timeout expired
It seems for me that for DTLS connection, SSL_connect() doesn't implement
cookies exchange.
I tryed to dig inside openssl s_client source code, but it's really too complex
for me, it seems like s_client doesn't use
SSL_connect, instead, using more low-level functions.
So, does anybody have any simple client-side implementation of DTLS over UDP
connection?
--
Александр Деревянко/Aleksander Derevianko
Нач. отдела новых аппаратно-программных средств
Бомбардье Транспортейшн (Сигнал)/Bombardier Transportation (Signal) Ltd.
T: +74959255370 Доб. 265
M: +79859229755
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] License change still scheduled for 1.1.1 ?
On 13/09/18 11:23, Cyrus Naliaka via openssl-users wrote: > 1.1.1 release still has the legacy license. > > Should we still expect a license change? > It is still our intention to change the license at some point however issues remain. It is likely to be some while before we are able to do so. Matt -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] License change still scheduled for 1.1.1 ?
1.1.1 release still has the legacy license. Should we still expect a license change? Thank you. ‐‐‐ Original Message ‐‐‐ On Monday, June 25, 2018 5:20 PM, Salz, Rich wrote: > - Do you still plan to switch to Apache license for the final 1.1.1 release? > > That is still our goal, as stated.-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] s_server -www -tls1_3: Firefox/Chrome not working
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
