无法连接到某些HTTPS站点
我刚搬到一个新的公寓，并通过路由器与互联网连接，我发现我无法连接到很多使用SSL的网站。
例如，尝试连接到PayPal：
curl -v https://paypal.com * About to connect() to paypal.com port 443 (#0) * Trying 66.211.169.3... connected * successfully set certificate verify locations: * CAfile: none CApath: /etc/ssl/certs * SSLv3, TLS handshake, Client hello (1): * Unknown SSL protocol error in connection to paypal.com:443 * Closing connection #0 curl: (35) Unknown SSL protocol error in connection to paypal.com:443 curl -v -ssl https://paypal.com给出相同的输出。
对于某些网站，它有效：
curl -v https://www.google.com * About to connect() to www.google.com port 443 (#0) * Trying 74.125.235.112... connected * successfully set certificate verify locations: * CAfile: none CApath: /etc/ssl/certs * SSLv3, TLS handshake, Client hello (1): * SSLv3, TLS handshake, Server hello (2): * SSLv3, TLS handshake, CERT (11): * SSLv3, TLS handshake, Server key exchange (12): * SSLv3, TLS handshake, Server finished (14): * SSLv3, TLS handshake, Client key exchange (16): * SSLv3, TLS change cipher, Client hello (1): * SSLv3, TLS handshake, Finished (20): * SSLv3, TLS change cipher, Client hello (1): * SSLv3, TLS handshake, Finished (20): * SSL connection using ECDHE-RSA-RC4-SHA * Server certificate: * subject: C=US; ST=California; L=Mountain View; O=Google Inc; CN=www.google.com * start date: 2011-10-26 00:00:00 GMT * expire date: 2013-09-30 23:59:59 GMT * common name: www.google.com (matched) * issuer: C=ZA; O=Thawte Consulting (Pty) Ltd.; CN=Thawte SGC CA * SSL certificate verify ok. > GET / HTTP/1.1 > User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3 > Host: www.google.com > Accept: */* > < HTTP/1.1 302 Found < Location: https://www.google.co.jp/ . . .
我正在使用Ubuntu 12.04，同时安装了Windows 7。 这些网站适用于Windows 🙁
不确定此信息是否有帮助，但我运行ifconfig并获得以下信息：
eth0 Link encap:Ethernet HWaddr 1c:c1:de:bc:e2:4f inet6 addr: 2408:c3:7fff:991:686b:8d18:81b3:8dd1/64 Scope:Global inet6 addr: 2408:c3:7fff:991:1ec1:deff:febc:e24f/64 Scope:Global inet6 addr: fe80::1ec1:deff:febc:e24f/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:87075 errors:0 dropped:0 overruns:0 frame:0 TX packets:54522 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:78167937 (78.1 MB) TX bytes:10016891 (10.0 MB) Interrupt:46 Base address:0x4000 eth1 Link encap:Ethernet HWaddr ac:81:12:0d:93:80 inet6 addr: fe80::ae81:12ff:fe0d:9380/64 Scope:Link UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:498 TX packets:0 errors:26 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) Interrupt:17 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:630 errors:0 dropped:0 overruns:0 frame:0 TX packets:630 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:39592 (39.5 KB) TX bytes:39592 (39.5 KB) ppp0 Link encap:Point-to-Point Protocol inet addr:180.57.228.200 PtP:118.23.8.175 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1 RX packets:39631 errors:0 dropped:0 overruns:0 frame:0 TX packets:22391 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:3 RX bytes:43462054 (43.4 MB) TX bytes:2834628 (2.8 MB)
我跑过PING：
ping www.paypal.com PING e6166.b.akamaiedge.net (184.31.66.234) 56(84) bytes of data. 64 bytes from a184-31-66-234.deploy.akamaitechnologies.com (184.31.66.234): icmp_req=1 ttl=54 time=15.3 ms 64 bytes from a184-31-66-234.deploy.akamaitechnologies.com (184.31.66.234): icmp_req=2 ttl=54 time=15.0 ms 64 bytes from a184-31-66-234.deploy.akamaitechnologies.com (184.31.66.234): icmp_req=3 ttl=54 time=15.2 ms 64 bytes from a184-31-66-234.deploy.akamaitechnologies.com (184.31.66.234): icmp_req=4 ttl=54 time=17.2 ms 64 bytes from a184-31-66-234.deploy.akamaitechnologies.com (184.31.66.234): icmp_req=5 ttl=54 time=16.6 ms 64 bytes from a184-31-66-234.deploy.akamaitechnologies.com (184.31.66.234): icmp_req=6 ttl=54 time=16.7 ms 64 bytes from a184-31-66-234.deploy.akamaitechnologies.com (184.31.66.234): icmp_req=7 ttl=54 time=14.8 ms ^C --- e6166.b.akamaiedge.net ping statistics --- 7 packets transmitted, 7 received, 0% packet loss, time 6009ms rtt min/avg/max/mdev = 14.878/15.890/17.214/0.901 ms
没有www：
ping paypal.com PING paypal.com (66.211.169.66) 56(84) bytes of data. ^C --- paypal.com ping statistics --- 303 packets transmitted, 0 received, 100% packet loss, time 302265ms
TRACEROUTE：
traceroute www.paypal.com traceroute to www.paypal.com (184.31.66.234), 30 hops max, 60 byte packets 1 118.23.8.175 (118.23.8.175) 8.424 ms 8.404 ms 8.540 ms 2 118.23.10.121 (118.23.10.121) 8.212 ms 8.189 ms 8.162 ms 3 122.1.164.213 (122.1.164.213) 9.405 ms 11.359 ms 13.469 ms 4 60.37.55.165 (60.37.55.165) 8.049 ms 8.072 ms 8.040 ms 5 118.23.168.89 (118.23.168.89) 8.574 ms 8.549 ms 8.558 ms 6 210.163.230.238 (210.163.230.238) 8.667 ms 7.605 ms 7.545 ms 7 xe-4-0-0.a21.osakjp01.jp.ra.gin.ntt.net (61.213.169.218) 18.255 ms 18.232 ms xe-3-0-0.a21.osakjp01.jp.ra.gin.ntt.net (61.213.162.206) 19.042 ms 8 * * * 9 * * * . . . 29 * * * 30 * * *
没有www：
traceroute paypal.com traceroute to paypal.com (66.211.169.66), 30 hops max, 60 byte packets 1 118.23.8.175 (118.23.8.175) 5.607 ms 5.674 ms 5.875 ms 2 118.23.10.121 (118.23.10.121) 5.468 ms 5.453 ms 5.576 ms 3 122.1.164.213 (122.1.164.213) 7.595 ms 10.062 ms 11.660 ms 4 60.37.55.165 (60.37.55.165) 5.684 ms 5.660 ms 5.635 ms 5 60.37.27.90 (60.37.27.90) 5.960 ms 5.924 ms 5.898 ms 6 ae-11.r20.tokyjp01.jp.bb.gin.ntt.net (129.250.12.197) 86.468 ms 30.960 ms 30.899 ms 7 as-1.r20.sttlwa01.us.bb.gin.ntt.net (129.250.4.189) 161.185 ms 144.343 ms 132.410 ms 8 ae-1.r05.sttlwa01.us.bb.gin.ntt.net (129.250.5.47) 139.008 ms 127.377 ms 139.050 ms 9 xe-0.sprint.sttlwa01.us.bb.gin.ntt.net (129.250.9.190) 116.006 ms 104.306 ms 115.954 ms 10 144.232.1.153 (144.232.1.153) 141.046 ms 129.870 ms 140.991 ms 11 sl-crs2-sj-0-5-2-0.sprintlink.net (144.232.18.204) 131.271 ms 131.248 ms 142.544 ms 12 sl-st31-sj-0-15-0-0.sprintlink.net (144.232.8.151) 129.543 ms 141.575 ms 141.066 ms 13 * * * 14 * * * . . . 29 * * * 30 * * *
tcpdump：
1 0.000000 114.178.88.59 66.211.169.66 TCP 76 37374 > https [SYN] Seq=0 Win=14520 Len=0 MSS=1452 SACK_PERM=1 TSval=68855 TSecr=0 WS=64 2 0.136291 66.211.169.66 114.178.88.59 TCP 80 https > 37374 [SYN, ACK] Seq=0 Ack=1 Win=4356 Len=0 MSS=1460 WS=1 TSval=3608913175 TSecr=68855 SACK_PERM=1 3 0.136322 114.178.88.59 66.211.169.66 TCP 68 37374 > https [ACK] Seq=1 Ack=1 Win=14528 Len=0 TSval=68889 TSecr=3608913175 4 0.137409 114.178.88.59 66.211.169.66 SSL 309 Client Hello 5 0.274446 66.211.169.66 114.178.88.59 SSL 95 [TCP Previous segment lost] Continuation Data 6 0.274469 114.178.88.59 66.211.169.66 TCP 80 [TCP Dup ACK 4#1] 37374 > https [ACK] Seq=242 Ack=1 Win=14528 Len=0 TSval=68923 TSecr=3608913175 SLE=2881 SRE=2908 7 7.117833 91.189.89.76 114.178.88.59 TLSv1 142 Application Data, Application Data 8 7.118823 114.178.88.59 91.189.89.76 TLSv1 216 Application Data, Application Data, Application Data, Application Data 9 7.393725 91.189.89.76 114.178.88.59 TCP 68 https > 41264 [ACK] Seq=75 Ack=149 Win=146 Len=0 TSval=875420654 TSecr=70634 10 60.301444 66.211.169.66 114.178.88.59 TCP 56 https > 37374 [RST, ACK] Seq=2908 Ack=242 Win=4597 Len=0
这是一个日本的ISP，即使我用连接到调制解调器/路由器的电缆连接我需要添加用户名和密码，但是使用Ubuntu的“有线”连接我无法添加这些。 我的室友告诉我创建一个OCN连接，但我不确定这是一个网络类型的名称还是仅仅是日本公司…但在看了她的电脑后我们发现它是一个PPPoE连接。 经过一些谷歌搜索，我了解到要创建一个PPPoE连接我需要创建一个DSL连接，我可以添加一个密码和用户名。 我还将“有线”连接更改为不自动连接。
如果我直接连接到调制解调器，我会遇到同样的问题。
我已经尝试将DSL MTU更改为500,1500,1492和1482，但它没有任何区别。
另外由于某些原因，Ubuntu并不总是拿起连接，我有时必须重新启动才能连接。
这是一个老问题，但对于那些通过谷歌来到这里的人来说，这将有所帮助。 问题是SSL上的碎片很糟糕，并破坏了协议。 如果您使用的是PPPOE，路由器/ DSL /电缆调制解调器中的正常MTU为1492.这太高了，会导致碎片。 1476是适用于大多数网站的神奇数字。 一些站点使用不同的SSL实现，因此1480可以工作，甚至1488.对于MOST兼容性，网络设备（路由器，调制解调器等）的WAN端MTU应为1476。
这里有几件事要尝试：
-
检查您的网卡设置。 您的eth接口都没有显示IPv4地址。 确保已打开IPv4（您可能需要重新建立与路由器的连接以续订IP）。 如果这不起作用，请尝试关闭IPv6支持，看看是否有所作为。 通过您的时钟右键单击网络图标（在以太网连接时，它是一对箭头，一个指向上方，另一个向下）并选择“编辑连接…”来执行此操作。 在“IPv4设置”选项卡中，确保将其设置为“自动（DHCP）”。 如果要关闭IPv6，请转到其选项卡并将其设置为“忽略”。
-
检查是否可以使用其他方法连接到站点。
ping无法为您无法连接的站点做出什么响应？ 如何使用traceroute（您可能必须安装traceroute才能使用它，仅供参考）？ 他们的回复可能会帮助您解决问题。 如果他们无法访问URL的服务器，那么它可能是DNS问题（但是，如果他们可以访问URL的服务器，但随后被删除，则可能只是意味着这些命令被阻止）。 -
绕过路由器。 如果您的路由器和调制解调器是两台不同的计算机，请尝试将计算机直接连接到调制解调器，看看是否有任何改变。
-
重启调制解调器和路由器。 有时，他们只是吮吸。
-
重启你的电脑。 有时，他们只是吮吸。
-
尝试使用其他电脑。 如果你有一台计算机，那么另一台计算机是否会出现故障？ 如果没有，那么它可能与您的特定计算机有关。
-
清除计算机的缓存，cookie等。有时，错误的会话cookie，缓存等可能会干扰连接到网站（我曾经有过谷歌的这个问题）。 清除它们并重新开始，看看你得到了什么。
-
断开所有VPN连接。 点对点协议通常用于VPN（PPP接口），VPN可能会干扰连接到站点。 通过右键单击您的时钟网络图标，找到“VPN连接”条目并确保没有选中列表（如果您没有“VPN连接”菜单项，那么您不要连接有一个设置）。 如果有任何已检查，那么您已连接到它，断开连接。
请记住：并非您所做的一切都会导致简单的“工作或失败”，服务器对您的请求的反应的任何变化都会告诉我们一些事情。 因此，如果您执行上述任何操作并获得新消息，请不要忘记更新您的问题。
我已经在实践中两次看到这种行为，我找到了以下解决方案。
- 本地网络中的某台计算机成功尝试了中间人攻击。 它是ARP欺骗网关，因此重定向所有流量通过这台机器，修改请求和其他令人讨厌的东西。 该机器运行Windows，发现感染了一些讨厌的恶意软件。 一旦该机器与网络物理断开连接，症状就会消失。
- 您或其他网关上的MTU问题 。 在IPv4网关中，如果其路由流量的网络的帧大小不同，则负责在网络上分段和重新组装IP分组。 对于使用PPPoE / PPPoA的DSL连接，MTU大小通常小于LAN侧的1500字节。 中间的路由器也会失败，您需要在路由器上启用TCP MSS Clamping 。 我总是需要在我以前的ISP的连接上设置它，但它解决的不仅仅是与SSL相关的问题。 检查您的调制解调器/路由器是否有这样的选项。 考虑这是一种解决方法。
- 我在网络中可能运行透明代理也传递SSL流量，但由于某种原因在TLSv1失败。 使用VPN连接时，相同的请求也有效。 害怕
尝试使用选项--sslv3运行curl。 如果这解决了它，那它就会发臭。
一般的尝试：
- 检查您是否在调制解调器/路由器上运行最新固件。 如果没有，请尝试升级。
-
使用
tcpdump或Whireshark捕获流量并对其进行分析（例如，在此处发布）。# 1. start the dump $ sudo tcpdump -w httpstrafficdump.pcap -i eth0 -s 0 port 443 # 2. open a new terminal window and do your HTTPS request there (curl/browser) # 3. end tcpdump (Ctrl+C) # 4. open the file in wireshark $ wireshark httpstrafficdump.pcap如果您反复收到重组错误或上一段丢失 ，这是由于错误的MTU大小导致丢包的明显迹象。
但是，HTTPS流量是加密的，很难从网络流量中自行分析。
编辑：
从您的tcpdump中，您的SSL问题的根源是明确的： TCP Previous segment lost 。 此处应用常规网络故障排除，但它可能超出了本地网络的范围，并且您的ISP出现问题。
感谢您的帮助，问题终于得到解决！
我试图限制MTU以确定它是否会有所帮助并最终使用pppoeconf设置PPPoE连接，因为它限制了我的MTU。 然后，我禁用了之前使用的DSL连接。
对于遇到类似问题的任何人，您可以通过键入sudo ppoeconf并按照说明尝试此解决方案。 然后，您可以与pon adsl-provider连接并与poff断开连接