Re: How to debug a TLSv1.3 protocol problem?

2020-05-19 Thread Claus Assmann 
On Tue, May 19, 2020, Matt Caswell wrote:

> > SSL_accept:error in TLSv1.3 early data

> This comes from this code in the info callback which you lifted from s_cb.c:

> Please could you modify this as follows:

> +ERR_print_errors(bio_err);

That's basically already in the code:
while ((l = ERR_get_error_line_data((const char **) , ,
(const char **) , )) != 0)
  log it ...
but that does not generate any output. Even if I add
the line you suggested there's no extra output
(to make sure there would be something I also added
an BIO_fprintf() and that output is shown, so it's not
a problem with the BIO).

I guess I have to figure out how to use wireshark for this.

Re: How to debug a TLSv1.3 protocol problem?

2020-05-19 Thread Matt Caswell 



On 19/05/2020 11:49, Claus Assmann wrote:
> On Mon, May 18, 2020, Viktor Dukhovni wrote:
> 
>> I'll strongly second Matt's request for a PCAP file.
> 
> If tcpdump is "good enough" then that should be attached.
> If wireshark and some TLS decoding is needed, then I need
> some time to figure that out.

The pcap file doesn't have the required info - however the SSL_trace
output gives the same kind of data, so that's good enough for now.


> I've added SSL_trace as suggested and the output is below.

Thanks that's useful.

> When I compare M1 with openssl s_client the main difference
> is that s_client has
> extension_type=padding
> but I don't see where/how M1 would turn that off (or where
> s_client turns it on?)

This shouldn't make any difference. I'd be very surprised if it was to
do with that.

>From the trace output I can see that the client sends a ClientHello to
the server. The server responds with an HRR, and the client re-issues a
new ClientHello. So far so good. However, at this point the server
doesn't like something about the new ClientHello and fails.


In your original email you got this output from the info callback on the
server side:

> SSL_accept:error in TLSv1.3 early data

This comes from this code in the info callback which you lifted from s_cb.c:

} else if (where & SSL_CB_EXIT) {
if (ret == 0)
BIO_printf(bio_err, "%s:failed in %s\n",
   str, SSL_state_string_long(s));
else if (ret < 0)
BIO_printf(bio_err, "%s:error in %s\n",
   str, SSL_state_string_long(s));
}

Please could you modify this as follows:

@@ -481,6 +481,7 @@ void apps_ssl_info_callback(const SSL *s, int where,
int ret)
 else if (ret < 0)
 BIO_printf(bio_err, "%s:error in %s\n",
str, SSL_state_string_long(s));
+ERR_print_errors(bio_err);
 }
 }


Now retry the handshake and send the output.

Thanks

Matt




> 
> 
> M8 client side:
> Sent Record
> Header:
>   Version = TLS 1.0 (0x301)
>   Content Type = Handshake (22)
>   Length = 512
> ClientHello, Length=508
>   client_version=0x303 (TLS 1.2)
>   Random:
> gmt_unix_time=0x2CE5293F
> random_bytes (len=28): 
> 60F8FD89D6BFFC32D30870CF534B271108BD7E00452949D9E2CECD7D
>   session_id (len=32): 
> E028F6D32F2F0FB8CC112794C7AA4E97AD76EDF6B955F49B51CA837F6115ABE2
>   cipher_suites (len=62)
> {0x13, 0x02} TLS_AES_256_GCM_SHA384
> {0x13, 0x03} TLS_CHACHA20_POLY1305_SHA256
> {0x13, 0x01} TLS_AES_128_GCM_SHA256
> {0xC0, 0x2C} TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
> {0xC0, 0x30} TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
> {0x00, 0x9F} TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
> {0xCC, 0xA9} TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
> {0xCC, 0xA8} TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
> {0xCC, 0xAA} TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
> {0xC0, 0x2B} TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
> {0xC0, 0x2F} TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
> {0x00, 0x9E} TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
> {0xC0, 0x24} TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
> {0xC0, 0x28} TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
> {0x00, 0x6B} TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
> {0xC0, 0x23} TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
> {0xC0, 0x27} TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
> {0x00, 0x67} TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
> {0xC0, 0x0A} TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
> {0xC0, 0x14} TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
> {0x00, 0x39} TLS_DHE_RSA_WITH_AES_256_CBC_SHA
> {0xC0, 0x09} TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
> {0xC0, 0x13} TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
> {0x00, 0x33} TLS_DHE_RSA_WITH_AES_128_CBC_SHA
> {0x00, 0x9D} TLS_RSA_WITH_AES_256_GCM_SHA384
> {0x00, 0x9C} TLS_RSA_WITH_AES_128_GCM_SHA256
> {0x00, 0x3D} TLS_RSA_WITH_AES_256_CBC_SHA256
> {0x00, 0x3C} TLS_RSA_WITH_AES_128_CBC_SHA256
> {0x00, 0x35} TLS_RSA_WITH_AES_256_CBC_SHA
> {0x00, 0x2F} TLS_RSA_WITH_AES_128_CBC_SHA
> {0x00, 0xFF} TLS_EMPTY_RENEGOTIATION_INFO_SCSV
>   compression_methods (len=1)
> No Compression (0x00)
>   extensions, length = 373
> extension_type=ec_point_formats(11), length=4
>   uncompressed (0)
>   ansiX962_compressed_prime (1)
>   ansiX962_compressed_char2 (2)
> extension_type=supported_groups(10), length=12
>   ecdh_x25519 (29)
>   secp256r1 (P-256) (23)
>   ecdh_x448 (30)
>   secp521r1 (P-521) (25)
>   secp384r1 (P-384) (24)
> extension_type=encrypt_then_mac(22), length=0
> extension_type=extended_master_secret(23), length=0
> extension_type=signature_algorithms(13), length=48
>

Re: How to debug a TLSv1.3 protocol problem?

2020-05-19 Thread Claus Assmann 
On Mon, May 18, 2020, Viktor Dukhovni wrote:

> I'll strongly second Matt's request for a PCAP file.

If tcpdump is "good enough" then that should be attached.
If wireshark and some TLS decoding is needed, then I need
some time to figure that out.

> The client trace looks rather odd, why is writing the hello
> again after CCS?  I don't recall what happens with HRR

Maybe M1 doesn't get an answer?

> (Hello retry request) when client's initial keyshare is
> not usable on the server...  Any unusual signature algorithm
> preferences in this particular client?

AFIACT none at all.

I've added SSL_trace as suggested and the output is below.
When I compare M1 with openssl s_client the main difference
is that s_client has
extension_type=padding
but I don't see where/how M1 would turn that off (or where
s_client turns it on?)


M8 client side:
Sent Record
Header:
  Version = TLS 1.0 (0x301)
  Content Type = Handshake (22)
  Length = 512
ClientHello, Length=508
  client_version=0x303 (TLS 1.2)
  Random:
gmt_unix_time=0x2CE5293F
random_bytes (len=28): 
60F8FD89D6BFFC32D30870CF534B271108BD7E00452949D9E2CECD7D
  session_id (len=32): 
E028F6D32F2F0FB8CC112794C7AA4E97AD76EDF6B955F49B51CA837F6115ABE2
  cipher_suites (len=62)
{0x13, 0x02} TLS_AES_256_GCM_SHA384
{0x13, 0x03} TLS_CHACHA20_POLY1305_SHA256
{0x13, 0x01} TLS_AES_128_GCM_SHA256
{0xC0, 0x2C} TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
{0xC0, 0x30} TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
{0x00, 0x9F} TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
{0xCC, 0xA9} TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
{0xCC, 0xA8} TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
{0xCC, 0xAA} TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
{0xC0, 0x2B} TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
{0xC0, 0x2F} TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
{0x00, 0x9E} TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
{0xC0, 0x24} TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
{0xC0, 0x28} TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
{0x00, 0x6B} TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
{0xC0, 0x23} TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
{0xC0, 0x27} TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
{0x00, 0x67} TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
{0xC0, 0x0A} TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
{0xC0, 0x14} TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
{0x00, 0x39} TLS_DHE_RSA_WITH_AES_256_CBC_SHA
{0xC0, 0x09} TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
{0xC0, 0x13} TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
{0x00, 0x33} TLS_DHE_RSA_WITH_AES_128_CBC_SHA
{0x00, 0x9D} TLS_RSA_WITH_AES_256_GCM_SHA384
{0x00, 0x9C} TLS_RSA_WITH_AES_128_GCM_SHA256
{0x00, 0x3D} TLS_RSA_WITH_AES_256_CBC_SHA256
{0x00, 0x3C} TLS_RSA_WITH_AES_128_CBC_SHA256
{0x00, 0x35} TLS_RSA_WITH_AES_256_CBC_SHA
{0x00, 0x2F} TLS_RSA_WITH_AES_128_CBC_SHA
{0x00, 0xFF} TLS_EMPTY_RENEGOTIATION_INFO_SCSV
  compression_methods (len=1)
No Compression (0x00)
  extensions, length = 373
extension_type=ec_point_formats(11), length=4
  uncompressed (0)
  ansiX962_compressed_prime (1)
  ansiX962_compressed_char2 (2)
extension_type=supported_groups(10), length=12
  ecdh_x25519 (29)
  secp256r1 (P-256) (23)
  ecdh_x448 (30)
  secp521r1 (P-521) (25)
  secp384r1 (P-384) (24)
extension_type=encrypt_then_mac(22), length=0
extension_type=extended_master_secret(23), length=0
extension_type=signature_algorithms(13), length=48
  ecdsa_secp256r1_sha256 (0x0403)
  ecdsa_secp384r1_sha384 (0x0503)
  ecdsa_secp521r1_sha512 (0x0603)
  ed25519 (0x0807)
  ed448 (0x0808)
  rsa_pss_pss_sha256 (0x0809)
  rsa_pss_pss_sha384 (0x080a)
  rsa_pss_pss_sha512 (0x080b)
  rsa_pss_rsae_sha256 (0x0804)
  rsa_pss_rsae_sha384 (0x0805)
  rsa_pss_rsae_sha512 (0x0806)
  rsa_pkcs1_sha256 (0x0401)
  rsa_pkcs1_sha384 (0x0501)
  rsa_pkcs1_sha512 (0x0601)
  ecdsa_sha224 (0x0303)
  ecdsa_sha1 (0x0203)
  rsa_pkcs1_sha224 (0x0301)
  rsa_pkcs1_sha1 (0x0201)
  dsa_sha224 (0x0302)
  dsa_sha1 (0x0202)
  dsa_sha256 (0x0402)
  dsa_sha384 (0x0502)
  dsa_sha512 (0x0602)
extension_type=supported_versions(43), length=9
  TLS 1.3 (772)
  TLS 1.2 (771)
  TLS 1.1 (770)
  TLS 1.0 (769)
extension_type=psk_key_exchange_modes(45), length=2
  psk_dhe_ke (1)
extension_type=key_share(51), length=38
NamedGroup: ecdh_x25519 (29)
key_exchange:  (len=32): 
3E7E05E66F3F978082E7445E0A6FA9C73F4F4C1E6423AA3FAB7B80C8E521F629
extension_type=padding(21), length=224
   - 00

Re: How to debug a TLSv1.3 protocol problem?

2020-05-19 Thread Claus Assmann 
On Tue, May 19, 2020, Jan Just Keijser wrote:

> FWIW:  adding TLS 1.3 support to my EAP-TLS code got me stumped for a while as
> well. I eventually added up the following snippet:

> SSL_CTX_set_session_cache_mode(ctx, SSL_SESS_CACHE_CLIENT |
> SSL_SESS_CACHE_NO_INTERNAL_STORE);
> SSL_CTX_sess_set_new_cb(ctx, ssl_new_session_cb);

Thanks, I actally added the callback yesterday based on reading
s_client.c.  It didn't change anything :-(

Re: How to debug a TLSv1.3 protocol problem?

2020-05-19 Thread Jan Just Keijser 

Hi Claus,

On 18/05/20 20:59, Claus Assmann wrote:

On Mon, May 18, 2020, Alexander Gryanko wrote:

[thanks for the hints, I will try that ASAP]


But first of all, check your cert type. Looks like you are using non-RSA
cert which is not supported by S8.

As I wrote: it works fine if I don't use TLSv1.3 or if I use openssl
s_client with TLSv1.3 (it is an RSA cert and I also tested against
another S8 server which uses a Let's Encrypt cert).
FWIW:  adding TLS 1.3 support to my EAP-TLS code got me stumped for a 
while as well. I eventually added up the following snippet:


    /* Set up a SSL Session cache with a callback. This is needed for 
TLSv1.3+.
 * During the initial handshake the server signals to the client 
early on

 * that the handshake is finished, even before the client has sent its
 * credentials to the server. The actual connection (and moment 
that the
 * client sends its credentials) only starts after the arrival of 
the first

 * session ticket. The 'ssl_new_session_cb' catches this ticket.
 */
    SSL_CTX_set_session_cache_mode(ctx, SSL_SESS_CACHE_CLIENT | 
SSL_SESS_CACHE_NO_INTERNAL_STORE);

    SSL_CTX_sess_set_new_cb(ctx, ssl_new_session_cb);



with

int ssl_new_session_cb(SSL *s, SSL_SESSION *sess)
{
    dbglog("EAP-TLS: Post-Handshake New Session Ticket arrived:");

    /* always return success */
    return 1;
}


This callback is necessary as otherwise the client thinks the session 
handshake is done too soon (and in my case, it does not bother to send 
any client-side certificate info to the server).


Perhaps you are seeing something similar? If not, then sorry for the noise.

HTH,

JJK / Jan Just Keijser