The context has a new parameter client_authentication to enable/disable the feature.

Should fix: https://github.com/h2o/picotls/issues/116

I create this pull request to get some feedback. The implementation should be finished.

I still want to add some testing to ensure that everything works as expected :)

The rule we have now is very lax. We accept 0-RTT unless we see an unexpectedly old ticket (i.e., issued more than 10 seconds ago).

            int64_t delta = (now - issue_at) - (identity->obfuscated_ticket_age - age_add);
            if (delta <= PTLS_EARLY_DATA_MAX_DELAY)
                *accept_early_data = 1;

This is fine when the max_early_data_size is small (compared to the size of the TCP receive buffer) and if the application protocol has a way to delay the processing of 0-RTT data (e.g., HTTP 425).

However, considering the fact that picotls might be used for application protocols other than HTTP, it's worth considering tightening the limits (we do not check the lower bound at all!), or providing a hook to customize reuse detection.

wireshark: Wireshark 2.3.0-3008-g71905a3 picotls: the latest of the kazuho/draft19 branch TLS 1.3 ID 19 server: www.mew.org:13443

I got packet dump between cli and www.mew.org:

% sudo tcpdump -i en0 -s 0 -x -w dump.pcap port 13443

% ./cli -l ~/key.log www.mew.org 13443

This TLS 1.3 ID 19 communication has no problem.

Then I tried to visualize dump.pcap with Wireshark. Plain parts, CH and SH, are displayed well. (Thank you!) But after letting key.log to Wireshark, nothing happens. That is, encrypted record are not decrypted.

Here is key.log:

% cat key.log 
SERVER_HANDSHAKE_TRAFFIC_SECRET bd4e5e9078115ce037cf5280b5e1b343ae778a045b79cdce78b48451f192e140 a4ed5073e772aab348036d0070ea7836ec9c2766b776e5e3299cfd5f883151ac
CLIENT_HANDSHAKE_TRAFFIC_SECRET bd4e5e9078115ce037cf5280b5e1b343ae778a045b79cdce78b48451f192e140 28a138be355b1d431971be591d53658030fb79d51f65271bce6f97b6a0d2c541
SERVER_TRAFFIC_SECRET_0 bd4e5e9078115ce037cf5280b5e1b343ae778a045b79cdce78b48451f192e140 5d9c27a2129f3cbd5f1e9192f2d689bf602ca23a556959a7ddc11e1e6a686dbc
CLIENT_TRAFFIC_SECRET_0 bd4e5e9078115ce037cf5280b5e1b343ae778a045b79cdce78b48451f192e140 eb633ab1cf4abb4a5e9023f4e41cd31b56e48dc5715bd48925e4e2d5aa50b163

Can you add support of new ke for SSLKEYLOFILE (premaster)

https://boringssl-review.googlesource.com/#/c/8841/

I will be help to add decrypt on #wireshark

I am trying to find how to implement HRR in QUIC, and I am not sure how to do such things as:

1. Tell PicoTLS to not accept the Client Hello and generate a Cookie instead.

2. Tell the client to consume the cookie: is it sufficient to just send the TLS message through the normal handshake API?

3. Tell the server to verify the Cookie. Again, is it sufficient to pipe the messages through the handshake API?

If PicoTLS does not in fact support HRR, I suppose that the server application could generate the HRR and the cookie, and that the client could parse it and extract the Cookie extension. Then, client and server could use the handshake extension mechanism to send and verify the cookie. But that's quite a bit of work, and I would rather not have to do that...

when using a custom certificate verification callback in picoquic_enable_custom_verify_certificate_callback currently no algo values are installed on the callback object, so we get segfaulted in push_signature_algorithms during the handshake.

the algo values are hidden inside openssl.c, and ptls_openssl_init_verify_certificate allocates an X509_STORE if you pass in NULL so i figured this is the best solution?

also SNI was broken for me. but adopting this new way corrects it.

and openssl says...

Applications are strongly advised to use this interface in preference to explicitly calling X509_check_host(3), hostname checks may be out of scope with the DANE-EE(3) certificate usage, and the internal check will be suppressed as appropriate when DANE verification is enabled.

https://www.openssl.org/docs/man1.1.0/man3/X509_VERIFY_PARAM_set1_host.html

this approach also unifies the verification and makes other vectors of verification simply appendable.

my server certificate looks like this:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 4096 (0x1000)
        Signature Algorithm: ED25519
        Issuer: C = US, ST = NY, O = Test Inc., OU = Test Intermediary CA, CN = 1nt3r, emailAddress = [email protected]
        Validity
            Not Before: Mar 23 16:16:10 2021 GMT
            Not After : Jun  9 16:16:10 2029 GMT
        Subject: C = US, ST = NY, L = NYC, O = Test Inc., OU = Test Intermediary CA, CN = server, emailAddress = [email protected]
        Subject Public Key Info:
            Public Key Algorithm: ED25519
                ED25519 Public-Key:
                pub:
                    c1:ce:ec:2e:94:85:e1:40:88:dc:be:82:73:71:ca:
                    96:12:6c:f0:ff:82:43:76:bf:10:2b:ea:f0:be:34:
                    45:85
        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:FALSE
            X509v3 Subject Key Identifier: 
                7E:2B:3F:64:2F:C6:90:F1:C9:94:7B:A5:06:1F:51:F7:D1:90:90:8B
            X509v3 Authority Key Identifier: 
                keyid:31:BC:26:9B:7D:39:22:0F:3C:D0:58:F3:DC:1E:B9:33:A3:24:96:9D
                DirName:/C=US/ST=NY/L=NYC/O=Test Inc./OU=Testing Root CA/CN=r00t/[email protected]
                serial:10:00

            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage: 
                TLS Web Client Authentication
            X509v3 Subject Alternative Name: 
                IP Address:0.0.0.0, IP Address:127.0.0.1, IP Address:0:0:0:0:0:0:0:1, DNS:localhost, DNS:0.0.0.0, DNS:127.0.0.1, DNS:::1
    Signature Algorithm: ED25519
         20:e7:35:10:ee:ef:c6:4e:57:a5:da:b0:c0:ea:34:45:99:30:
         e3:4d:75:6e:d4:4f:61:e7:92:85:58:96:7d:6b:fa:a8:0a:94:
         d0:e5:b7:43:f3:09:77:2a:2f:85:07:3d:21:43:7b:1b:45:50:
         b3:dd:71:6d:8a:cb:4c:8e:44:0c

3fd9529 is the fix by keeping (-k) statically-named temporary files used by dtrace, which leads to a build failure like:

 Traceback (most recent call last):
  File "/usr/bin/dtrace", line 445, in <module>
    sys.exit(main())
  File "/usr/bin/dtrace", line 432, in main
    os.remove(fname)
FileNotFoundError: [Errno 2] No such file or directory: '/home/goro/ghq/github.com/h2o/picotls/b/picotls-probes.o.dtrace-temp.c'

where picotls-probes.o.dtrace-temp.c is the temp file used by dtrace and has been removed by another sibling processes.

Picotls has a default verifier for server certificate. That default verifier (verify_cert_chain) verifies that the server name is documented before calling openssl to check the chain. There is an assert for that at line 1008 in lib/openssl.c.

It is very clear that if the server name is not specified, verifying the cert chain is pointless. But then, we have lots of picoquic users who just want to test the transport features, and start a test with something like "picoquicdemo 127.0.0.1 4433", and then trigger the assert.

Is it possible to change the behavior and simply "return 0" if the server name is not specified? Or, do I need to just create my own version of the verifier that will bypass the tests in these cases?

Does picotls already supports sending client certificates and the verification of these certificates?

After looking into the code, I'm not 100% sure, but assume that this is currently not supported.

The Visual Studio project includes a basic test: a console application that performs a handshake "in memory", thus exercising both server and client functions.

At the moment, the encrypt API provided by picotls only receives one ptl_iovec_t, which in turn produces an AEAD record. This leads to inefficiency when multiple fragments of data has to be sent concatenated.

To give an example, HTTP/2 implementations typically split HTTP response into small chunks, prepending HTTP/2 frame headers to each of those chunks, before they pass them to the TLS stack. At the moment, HTTP/2 implementations have to either:

• a) build a flat image that has the HTTP/2 frame headers and chunks of response being concatenated, or
• b) call ptls_send for encrypting the HTTP/2 frame header, then make a separate call for encrypting the response chunk.

a is inefficient when the implementation already has the response buffered in memory, because an extra copy would be required to concatenate the HTTP/2 frame header and the chunk of the response. b is inefficient due to generating a tiny TLS record that contains only the HTTP/2 frame header, not to mention the privacy aspect of leaking information through how things are chunked.

To address this problem, this pull request attempts to introduce a variant of ptls_send function that accepts a vector of buffers as input.

At the moment, this PR also replaces the init -> update -> final API at the AEAD layer with a new vectorized API as well. The rationale is that vectorized APIs are expected to provide better performance (as they can be integrated tighter to the encrypting code, see #384). But we can probably keep the existing ones deprecated.

Got this warning when running valgrind to check picoquic code. The issue happens inside openssl, accessed through picotls

This is part of the valgrind report:

==4255== 1526 errors in context 1 of 1: ==4255== Conditional jump or move depends on uninitialised value(s) ==4255== at 0x4AF62A4: ??? (in /usr/lib/x86_64-linux-gnu/libcrypto.so.3) ==4255== by 0x4AF6581: ??? (in /usr/lib/x86_64-linux-gnu/libcrypto.so.3) ==4255== by 0x49F70F4: EVP_DecryptFinal_ex (in /usr/lib/x86_64-linux-gnu/libcrypto.so.3) ==4255== by 0x1C6724: aead_do_decrypt (openssl.c:962) ==4255== by 0x182F26: picoquic_remove_packet_protection (packet.c:677) ==4255== by 0x18381D: picoquic_parse_header_and_decrypt (packet.c:783) ==4255== by 0x186149: picoquic_incoming_segment (packet.c:2157)

Have we seen that already?

When using BoringSSL:

• X25519 key exchange uses the dedicated X25519 API in order for the scalar to be properly clamped.
• AEADs use the dedicated AEAD API. New ciphers such as ChaChaPoly are not available when using the old API.
• Blowfish has been deprecated and was removed from libcrypto; linking the decrepit library is required.
• BoringSSL doesn't come with a pkgconfig file, so defining BORINGSSL_ROOT_DIR is required.

The code of the function is:

int ptls_fusion_is_supported_by_cpu(void)
{
    unsigned leaf1_ecx, leaf7_ebx;

    { /* GCC-specific code to obtain CPU features */
        unsigned leaf_cnt;
        __asm__("cpuid" : "=a"(leaf_cnt) : "a"(0) : "ebx", "ecx", "edx");
        if (leaf_cnt < 7)
            return 0;
        __asm__("cpuid" : "=c"(leaf1_ecx) : "a"(1) : "ebx", "edx");
        __asm__("cpuid" : "=b"(leaf7_ebx) : "a"(7), "c"(0) : "edx");
    }

    /* AVX2 */
    if ((leaf7_ebx & (1 << 5)) == 0)
        return 0;
    /* AES */
    if ((leaf1_ecx & (1 << 25)) == 0)
        return 0;
    /* PCLMUL */
    if ((leaf1_ecx & (1 << 1)) == 0)
        return 0;

    return 1;
}

Valgrind complains that the "Conditional jump or move depends on uninitialized value". This is very annoying, because the message will fill the valgrind logs when testing code that uses picotls.

I think this could be fixed by changing the declaration to unsigned leaf_cnt = 0;.