When surfing to "https://devmanual.gentoo.org", the browser keeps on waiting ("Connecting to devmanual.gentoo.org...") and never finishes until a time-out occurs (from the client side). Users of HTTPS everywhere are affected here as any attempt to reach http://devmanual.gentoo.org is redirected to the HTTPS site. Reproducible: Always Steps to Reproduce: Surf to https://devmanual.gentoo.org Actual Results: Browser stalls, devmanual.gentoo.org is not reachable over HTTPS Expected Results: Either be reachable over HTTPS as well, or have the client immediately (or at least within a valid timeframe) return with a message that the site is not available. Development on the rules of HTTPS Everywhere have been informed and requested to remove the https:// for devmanual.g.o for the time being. I suppose the endless waiting is part of an anti-DoS or other firewall setting? If so, then the "Expected Results" can be reduced to "Be reachable over HTTPS" and the bug can be updated to a feature request (as I can understand HTTPS for a static site isn't that beneficial).
It does not work by design, yes.
If this is entirely be design, then the bug can be marked as invalid. In that case, I'll follow up on the https everywhere developers that this is intended behavior.
Yes, closing as it does not work by design as stated by darkside.
So there is *no* timeout by design? We have a proxy, apache itself or whatever listening on 443 to keep the connection alive until the user closes the connection? I don't believe that we want *this* behaviour...
Ok, just checked barbet, we don't have anything listening on 443 at all but we're accepting connections to 443. So we need a proper solution IMHO.
It seems that for some reason the host itself does not answer with an "RST/ACK" to the clients ACK which would cause the client to notice that the host rejects the connection attempt. So we will look into this.
s/to the clients ACK/to the clients SYN/
(In reply to comment #7) > s/to the clients ACK/to the clients SYN/ antarus@a01 ~/gentoo/gentoo/users/antarus/projects/infra $ sudo tcptraceroute barbet.gentoo.org 443 1024 Selected device eth0, address 10.1.10.11, port 35902 for outgoing packets Tracing the path to barbet.gentoo.org (140.211.166.187) on TCP port 443 (https), 30 hops max, 1024 byte packets 1 10.1.10.1 0.632 ms 0.772 ms 0.973 ms 2 50.131.146.1 2280.031 ms 145.176 ms 59.479 ms 3 * * * 4 te-1-11-0-1-ar01.oakland.ca.sfba.comcast.net (68.85.155.78) 14.316 ms 13.479 ms 14.432 ms 5 pos-2-1-0-0-cr01.sacramento.ca.ibone.comcast.net (68.86.90.141) 14.669 ms 21.697 ms 15.246 ms 6 pos-0-4-0-0-cr01.sanjose.ca.ibone.comcast.net (68.86.85.50) 15.038 ms 15.565 ms 15.676 ms 7 xe-5-2-0.edge1.SanJose1.Level3.net (4.71.118.49) 15.265 ms 15.801 ms 16.742 ms 8 vlan60.csw1.SanJose1.Level3.net (4.69.152.62) 15.574 ms 16.994 ms 15.552 ms 9 ae-62-62.ebr2.SanJose1.Level3.net (4.69.153.17) 15.376 ms 65.526 ms 14.454 ms 10 ae-7-7.ebr1.Seattle1.Level3.net (4.69.132.50) 33.200 ms 31.654 ms 35.977 ms 11 ae-11-51.car1.Seattle1.Level3.net (4.69.147.131) 34.128 ms 33.098 ms 31.706 ms 12 4.53.150.46 36.757 ms 36.073 ms 36.721 ms 13 corv-car1-gw.nero.net (207.98.64.177) 38.043 ms 38.497 ms 39.787 ms 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 *^C So in sort we should email the OSL and ask them why our https traffic is being blackholed (as opposed to normal rfc behavior.) antarus@a01 ~/gentoo/gentoo/users/antarus/projects/infra $ sudo tcptraceroute barbet.gentoo.org 80 1024 Selected device eth0, address 10.1.10.11, port 38071 for outgoing packets Tracing the path to barbet.gentoo.org (140.211.166.187) on TCP port 80 (http), 30 hops max, 1024 byte packets 1 10.1.10.1 0.570 ms 0.882 ms 0.965 ms 2 50.131.146.1 75.427 ms 29.389 ms 29.460 ms 3 * * * 4 te-1-11-0-1-ar01.oakland.ca.sfba.comcast.net (68.85.155.78) 16.498 ms 13.179 ms 13.066 ms 5 pos-2-1-0-0-cr01.sacramento.ca.ibone.comcast.net (68.86.90.141) 15.297 ms 32.290 ms 16.034 ms 6 pos-0-4-0-0-cr01.sanjose.ca.ibone.comcast.net (68.86.85.50) 15.317 ms 15.074 ms 15.126 ms 7 xe-5-2-0.edge1.SanJose1.Level3.net (4.71.118.49) 20.475 ms 14.886 ms 14.096 ms 8 vlan60.csw1.SanJose1.Level3.net (4.69.152.62) 16.067 ms 18.429 ms 14.589 ms 9 ae-62-62.ebr2.SanJose1.Level3.net (4.69.153.17) 31.624 ms 15.008 ms 28.184 ms 10 ae-7-7.ebr1.Seattle1.Level3.net (4.69.132.50) 38.406 ms 65.476 ms 37.227 ms 11 ae-11-51.car1.Seattle1.Level3.net (4.69.147.131) 38.899 ms 35.338 ms 33.754 ms 12 4.53.150.46 36.567 ms 36.414 ms 34.927 ms 13 corv-car1-gw.nero.net (207.98.64.177) 38.669 ms 38.345 ms 50.149 ms 14 barbet.gentoo.osuosl.org (140.211.166.187) [open] 46.627 ms 39.032 ms 58.045 ms
I filed a support ticket with the osl. -A
ok so it is not the OSL. Basically we have a kernel security thingajig that does not send RST's for packets that come in when we don't have a daemon listening on that port. The easy fix is to just set apache up for https on that box. -A
WORKSFORME now, and it's also part of the HTTPS-Everywhere default-on ruleset, so... RESOLVED FIXED I guess?
