Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

TLS client not responding to key update when KeyUpdate is KeyUpdateRequest.update_requested #22508

Open
2lchain opened this issue Jan 16, 2025 · 0 comments · May be fixed by #22512
Open

TLS client not responding to key update when KeyUpdate is KeyUpdateRequest.update_requested #22508

2lchain opened this issue Jan 16, 2025 · 0 comments · May be fixed by #22512
Labels
bug Observed behavior contradicts documented or intended behavior

Comments

@2lchain
Copy link

2lchain commented Jan 16, 2025

Zig Version

0.14.0-dev.2647+5322459a0

Steps to Reproduce and Observed Behavior

The error is evident in the Client.zig but I will also how to reproduce it with openssl s_server.

openssl s_server -accept localhost:3000 -tls1_3

Run this program. program should block to give a chance to trigger key update

const std = @import("std");
const Client = std.crypto.tls.Client;

pub fn main() !void {
    const addr = try std.net.Address.parseIp("127.0.0.1", 3000);
    const stream = try std.net.tcpConnectToAddress(addr);

    var client = try Client.init(stream, .{
        .ca = .no_verification,
        .host = .no_verification
    });

    var buf: [20]u8 = undefined;
// block here
    _ = try client.readAll(stream, buf[0..]);

    std.debug.print("data: {s}\n", .{buf});

    _ = try client.write(stream, "ending connection...\n");

    _ = try client.writeEnd(stream, "", true);
}

type K at s_server terminal to trigger key update with KeyUpdateRequest.update_requested

type any 20 characters to unblock the program

Using default temp DH parameters
ACCEPT
-----BEGIN SSL SESSION PARAMETERS-----
MHMCAQECAgMEBAITAQQgShd2vbIgI+z6R/uAIJMk5o99v7bluT/4Tg4TgYu+t+8E
ICyjPo2S7OSzEzNodsRlDisLGkbbwuvcHl+FijWlElh2oQYCBGeJGt2iBAICHCCk
BgQEAQAAAK4HAgUAgerr3rMDAgEX
-----END SSL SESSION PARAMETERS-----
Shared ciphers:TLS_AES_128_GCM_SHA256:ECDHE-RSA-AES128-GCM-SHA256:TLS_AES_256_GCM_SHA384:ECDHE-RSA-AES256-GCM-SHA384:TLS_CHACHA20_POLY1305_SHA256:ECDHE-RSA-CHACHA20-POLY1305
Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:RSA+SHA256:RSA+SHA384:RSA+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA1:Ed25519
Shared Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:RSA+SHA256:RSA+SHA384:RSA+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:Ed25519
Supported groups: <NULL>:secp256r1:secp384r1:x25519
Shared groups: secp256r1:secp384r1:x25519
CIPHER is TLS_AES_128_GCM_SHA256
Secure Renegotiation IS NOT supported
K
SSL_do_handshake -> 1
ffffffffffffffffffffffffffffffffffffffff
ERROR
40B7930FF6720000:error:0A000119:SSL routines:ssl3_get_record:decryption failed or bad record mac:../ssl/record/ssl3_record.c:622:
shutting down SSL
CONNECTION CLOSED

tls client tried to close connection before it sends key update.

Expected Behavior

behave as stated in rfc 8446
@2lchain 2lchain added the bug Observed behavior contradicts documented or intended behavior label Jan 16, 2025
@2lchain 2lchain linked a pull request Jan 21, 2025 that will close this issue
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Observed behavior contradicts documented or intended behavior
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Update Client.zig to respond to a KeyUpdateRequest.update_requested 2lchain/zig
1 participant
@2lchain