Open Bug 1507215 Opened 7 years ago Updated 9 months ago

Consider extending happy eyeballs (or general connection establish retry) on failing/timed out TLS handshakes

Categories

(Core :: Networking: HTTP, enhancement, P3)

enhancement

Tracking

()

Tracking Status
firefox65 --- affected

People

(Reporter: mayhemer, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [http-conn][necko-triaged])

Filing under PSM, but this may overreach to HTTP. we can connect studioedge.akamaized.net (at 2a02:26f0:132::215:4a3a) but it never responds to Client Hello (checked in wireshark) and just sends a RST in 30s. we try several times, with the same IP(v6)! because of the retry logic in the http stack. action items: - check the server for misconfiguration (may be hard) - if not, check if we are doing something wrong move this bug to HTTP and: - consider extending happy eyeballs also on TLS handshakes (i.e. start a backup connection when TLS handshake takes too long and is using ipv6 (or simply try with the second family) - at least black list the ip from further attempts (a simple fix, IMO) ; may just try another IPv6 in the list that is also broken
Btw, Chrome 70 has the same issue...
And Edge too...
Moving to HTTP then, we can improve here, but definitely not a huge priority.
Component: Security: PSM → Networking: HTTP
Priority: -- → P3
Summary: studioedge.akamaized.net resolved to ipv6 doesn't response to TLS handshake → Consider extending happy eyeballs (or general connection establish retry) on failing/timed out TLS handshakes
Whiteboard: [http-conn] → [http-conn][necko-triaged]
https://studioedge.akamaized.net is fine for me (Hannover, Germany). studioedge.akamaized.net. 21573 IN CNAME a1689.dscw10.akamai.net. a1689.dscw10.akamai.net. 20 IN AAAA 2a02:26f0:120::211:7819 a1689.dscw10.akamai.net. 20 IN AAAA 2a02:26f0:120::211:7861 Also fine here: https://www.hardenize.com/report/studioedge.akamaized.net/1542217079#www_tls
I think it's a bug in my new home router. I can't connect https://janbambas.cz/ as well, likely same reason.
This can happen in the wild: tcp connection works but data over tcp does not. We can consider this in the future. Broken routers and middleboxes are the cause.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.