Re: [openssl-users] Generating CSR based on an x25519 public key

2017-10-23 Thread Kyle Hamilton
Out of curiosity, what are the algorithm identifiers for X25519 and Ed25519?

-Kyle H

On Mon, Oct 23, 2017 at 3:24 PM, Jakob Bohm  wrote:
> On 21/10/2017 15:38, Codarren Velvindron wrote:
>>
>> https://tls13.crypto.mozilla.org is using : The connection to this site is
>> encrypted and authenticated using a strong protocol (TLS 1.3), a strong key
>> exchange (X25519), and a strong cipher (AES_128_GCM).
>>
>> Using openssl standard tools is it possible to generate a CSR through
>> Ed25519 ?
>>
>
>
> If you look further into this test page, at least with my
> browser, it uses x25519 with a regular RSA certificate from
> Let's encrypt.  I don't know if they use a different
> certificate with other browsers based on checking some TLS
> extensions etc.
>
> The x25519 public key has no certificate, it is randomly
> generated for each connection and signed with the RSA key
> from the 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 mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


Re: [openssl-users] Generating CSR based on an x25519 public key

2017-10-23 Thread Jakob Bohm

On 21/10/2017 15:38, Codarren Velvindron wrote:
https://tls13.crypto.mozilla.org is using : The connection to this 
site is encrypted and authenticated using a strong protocol (TLS 1.3), 
a strong key exchange (X25519), and a strong cipher (AES_128_GCM).


Using openssl standard tools is it possible to generate a CSR through 
Ed25519 ?





If you look further into this test page, at least with my
browser, it uses x25519 with a regular RSA certificate from
Let's encrypt.  I don't know if they use a different
certificate with other browsers based on checking some TLS
extensions etc.

The x25519 public key has no certificate, it is randomly
generated for each connection and signed with the RSA key
from the 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


Re: [openssl-users] Early data based on SNI with OpenSSL 1.1.1

2017-10-23 Thread Matt Caswell


On 23/10/17 16:16, Olivier Houchard wrote:
> Hi,
> 
> I'm trying to use OpenSSL 1.1.1 to accept or reject early data based on
> the SNI, and I'm a bit confused on how to do so.
> The problem I have is, I don't know the SNI before the client hello
> callback is called, and at that time it seems to be too late to make a
> decision for early data. Either the callback is called from
> SSL_do_handshake(), and then any call to SSL_read_early_data() will fail
> with SSL_ERROR_SSL, and early data will be rejected, or it is called if
> I call SSL_read_early_data() first, but then early data will be
> considered accepted no matter what.
> 
> I tried returning -1 from the client hello callback, but if called from
> SSL_do_handshake to indicate early data are to be read, it seems to be too
> late to call SSL_read_early_data() anyway, and if called from
> SSL_read_early_data() to indicate we should stop reading early data, it
> mostly works, except as s->early_data_state will be
> SSL_EARLY_DATA_ACCEPT_RETRY, and so any call to SSL_Read() will fail
> because of that test in ssl_read_internal() :
> if (s->early_data_state == SSL_EARLY_DATA_CONNECT_RETRY
>|| s->early_data_state == SSL_EARLY_DATA_ACCEPT_RETRY) {
>   SSLerr(SSL_F_SSL_READ_INTERNAL,
>   ERR_R_SHOULD_NOT_HAVE_BEEN_CALLED);
>   return 0;
> }
> 
> Am I missing something obvious ? Is there any way I can accept or reject
> early data based on the SNI ?

>From the docs:

https://www.openssl.org/docs/manmaster/man3/SSL_set_max_early_data.html

"When a session is created between a server and a client the server will
specify the maximum amount of any early data that it will accept on any
future connection attempt. By default this is approximately 16k. A
server may override this default value by calling
SSL_CTX_set_max_early_data() or SSL_set_max_early_data() to set it for
the whole SSL_CTX or an individual SSL object respectively. Similarly
the SSL_CTX_get_max_early_data() and SSL_get_max_early_data() functions
can be used to obtain the current maximum early data settings for the
SSL_CTX and SSL objects respectively."

So, probably the best way to do this is to set the max early data for
the server CTXs that you don't want to accept early_data to 0. Then any
sessions they issue will not allow early_data to be used. If a client
does attempt to use that session to send early data then it then it will
be automatically rejected.

If that doesn't work for you another way (I think?) to do this would be
to set the max early data for that SSL object (using
SSL_set_max_early_data()) to 0 during the callback.

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


[openssl-users] Early data based on SNI with OpenSSL 1.1.1

2017-10-23 Thread Olivier Houchard
Hi,

I'm trying to use OpenSSL 1.1.1 to accept or reject early data based on
the SNI, and I'm a bit confused on how to do so.
The problem I have is, I don't know the SNI before the client hello
callback is called, and at that time it seems to be too late to make a
decision for early data. Either the callback is called from
SSL_do_handshake(), and then any call to SSL_read_early_data() will fail
with SSL_ERROR_SSL, and early data will be rejected, or it is called if
I call SSL_read_early_data() first, but then early data will be
considered accepted no matter what.

I tried returning -1 from the client hello callback, but if called from
SSL_do_handshake to indicate early data are to be read, it seems to be too
late to call SSL_read_early_data() anyway, and if called from
SSL_read_early_data() to indicate we should stop reading early data, it
mostly works, except as s->early_data_state will be
SSL_EARLY_DATA_ACCEPT_RETRY, and so any call to SSL_Read() will fail
because of that test in ssl_read_internal() :
if (s->early_data_state == SSL_EARLY_DATA_CONNECT_RETRY
   || s->early_data_state == SSL_EARLY_DATA_ACCEPT_RETRY) {
SSLerr(SSL_F_SSL_READ_INTERNAL,
ERR_R_SHOULD_NOT_HAVE_BEEN_CALLED);
return 0;
}

Am I missing something obvious ? Is there any way I can accept or reject
early data based on the SNI ?

Thanks !

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