Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Duplicate
-
5.3.0
-
None
-
None
Description
We noticed that occasionally upon a restart, the npn list built by ATS has garbage data (additional null bytes), resulting in the client failing to decode the ServerHello correctly. The problem would always go away with a restart and is hard to reproduce.
Here's a trace that shows the good vs bad npn lists in the ServerHello:
bad npn list (with spdy and http enabled):
Extension: next_protocol_negotiation Type: next_protocol_negotiation (0x3374) Length: 36 Next Protocol Negotiation Protocol string length: 8 Next Protocol: spdy/3.1 Protocol string length: 6 Next Protocol: spdy/3 Protocol string length: 8 Next Protocol: http/1.1 Protocol string length: 8 Next Protocol: http/1.0 Protocol string length: 0 Protocol string length: 0
good npn list:
Extension: next_protocol_negotiation Type: next_protocol_negotiation (0x3374) Length: 34 Next Protocol Negotiation Protocol string length: 8 Next Protocol: spdy/3.1 Protocol string length: 6 Next Protocol: spdy/3 Protocol string length: 8 Next Protocol: http/1.1 Protocol string length: 8 Next Protocol: http/1.0
Attachments
Issue Links
- duplicates
-
TS-3031 Race condition in SSLNextProtocolSet::advertiseProtocols
- Closed