-
Bug
-
Resolution: Fixed
-
P4
-
17, 21, 22
-
b18
-
Verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8334387 | 21.0.5-oracle | Prajwal Kumaraswamy | P4 | Resolved | Fixed | b01 |
JDK-8334454 | 21.0.5 | Martin Doerr | P4 | Resolved | Fixed | b01 |
JDK-8334184 | 17.0.13-oracle | Prajwal Kumaraswamy | P4 | Resolved | Fixed | b01 |
JDK-8334607 | 17.0.13 | Martin Doerr | P4 | Resolved | Fixed | b01 |
This can happen when the original session was established with a SNIMatcher and the resumption was performed without a SNIMatcher.
Reproducer attached. It performs 2 handshakes using the same SSLContext. The first handshake succeeds, the second aborts with "Tag mismatch". Expected result: both handshakes finish successfully.
Possible solution: make PreSharedKeyExtension.SHPreSharedKeyProducer return null if shc.isResumption is false.
- backported by
-
JDK-8334184 TLS 1.3 handshake fails if server_name doesn't match resuming session
- Resolved
-
JDK-8334387 TLS 1.3 handshake fails if server_name doesn't match resuming session
- Resolved
-
JDK-8334454 TLS 1.3 handshake fails if server_name doesn't match resuming session
- Resolved
-
JDK-8334607 TLS 1.3 handshake fails if server_name doesn't match resuming session
- Resolved
- links to
-
Commit openjdk/jdk17u-dev/c2dd771e
-
Commit openjdk/jdk21u-dev/f2e567ab
-
Commit openjdk/jdk/0259da92
-
Review openjdk/jdk17u-dev/2578
-
Review openjdk/jdk21u-dev/731
-
Review(master) openjdk/jdk/13669