无法连接到某些HTTPS网站

12

我刚搬到一间新公寓，并通过路由器与Internet连接，但发现无法连接到许多使用SSL的站点。

例如，尝试连接到贝宝：

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  P-t-P: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 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并不总是能够建立连接，有时我必须重新启动才能连接。

12.04 ssl https

— 思维空白
source

这些网站仅不curl与其他浏览器一起打开还是与其他浏览器一起打开？

— adempewolff 2012年

他们根本没有开放，我只是想找出问题出在哪里……

— mind.blank 2012年

@ mind.blank-当您尝试连接时浏览器会给您什么？如果从主窗口没有任何内容，请尝试安装Firebug（如果使用Firefox；如果使用Chrome，则内置了开发人员工具），将其打开，然后激活控制台和网络标签，看看是否有任何错误，然后在此处报告。

— Shauna 2012年

您之前使用过路由器还是全新的？另外，您还没有做任何愚蠢的事情并升级了ssl软件包，还是没有默认安装的任何内容？我可以正常访问所有这些站点（至少可以通过我的代理，中国随机阻止ssl协议），所以我猜测问题出在路由器还是升级/安装的软件包。

— adempewolff 2012年

@Shauna我正在使用Chrome，是说Error 7 (net::ERR_TIMED_OUT): The operation timed out。FireFox只会继续尝试加载，但不会加载（页面不会更改）。控制台和网络什么也没给我...

— mind.blank 2012年

11

这是一个老问题，但是对于那些通过Google到达这里的人来说，这将有所帮助。问题是SSL上的碎片损坏，并且破坏了协议。如果使用PPPOE，则路由器/ DSL /电缆调制解调器中的常规MTU为1492。该值太高，会导致碎片。1476是最适用于大多数站点的魔术数字。某些站点使用不同的SSL实现，因此1480可能可以工作，甚至1488也可以工作。为了实现MOST兼容性，网络设备（路由器，调制解调器等）的WAN端的MTU应该为1476。

— 遗憾溢出
source

1

我看不到碎片将如何破坏SSL。片段化的数据包将由IPv4中的路由器重组。SSL发生在TCP之上，在这个级别上您不会注意到这一点。我确实认为这与MTU值有关，但我认为您的解释不符合要求。我认为这与两端未同步的MTU设置有关，导致碎片数据包的错误重组。幻数可能适用于您的情况，但不适用于其他情况。

— gertvdijk

DF（“不分片”）位始终是通过设计对SSL流量设置的-分片是一个安全漏洞。碎片化的SSL数据包将被丢弃99.9％的时间。MTU在PPoE流量上过低会导致碎片。

— 后悔

这在PayPal网站上发生了。我尝试使用MTU 1476进行解决，但没有成功，但使用1480却有效。谢谢！

— 2015年

我花了早上6点至下午2点来尝试解决此问题，直到找到您的答复。非常感激！

— WayBehind '16

1

天啊！这使我能够sudo yum install docker-engine在CentOS 7盒子上添加yum.dockerproject.org存储库后：sudo ip link set mtu 1476 dev enp6s0将MTU从默认值1500降低到1476。通过来自同一网络上其他节点的https。

— jwd630 '16

3

这里有一些尝试的方法：

检查您的网卡设置。您的eth界面均未显示IPv4地址。确保已打开IPv4（您可能需要与路由器重新建立连接以更新IP）。如果那不起作用，请尝试关闭IPv6支持，看看是否有所作为。通过在时钟旁边右键单击网络图标（在以太网连接上，是一对箭头，一个指向上，另一个指向下）并选择“编辑连接...”来执行此操作。在“ IPv4设置”选项卡中，确保将其设置为“自动（DHCP）”。如果要关闭IPv6，请转到其选项卡并将其设置为“忽略”。
检查是否可以使用其他方法连接到站点。ping对于您无法连接的站点会有什么反应？怎么样traceroute（你可能必须安装跟踪路由使用它，仅供参考）？他们的回答可能会帮助您解决问题。如果它们无法访问URL的服务器，则可能是DNS问题（但是，如果它们可以访问URL的服务器，但是又被删除，则可能意味着这些命令已被阻止）。
绕过路由器。如果您的路由器和调制解调器是两台不同的计算机，请尝试将计算机直接连接到调制解调器，看看是否有任何改变。
重新启动调制解调器和路由器。有时，他们只是吮吸。
重启你的电脑。有时，他们只是吮吸。
尝试使用其他计算机。如果您拥有一台计算机，那么另一台计算机可以在该计算机出现故障的情况下工作吗？如果没有，则可能与您的特定计算机有关。
清除计算机的缓存，Cookie等。有时，会话错误的Cookie，缓存等可能会干扰到网站的连接（前一段时间我在Google上遇到过此问题）。清除它们并重新开始，看看会得到什么。
断开所有VPN连接。点对点协议通常用于VPN（PPP接口），并且VPN会干扰到站点的连接。右键单击时钟旁边的网络图标，找到“ VPN连接”条目，并确保未选中任何列表，以确保未连接到网络（如果您没有“ VPN连接”菜单项，那么您不会没有设置）。如果有任何检查，则表明您已连接到该设备，请断开与它的连接。

请记住：并非您所做的任何事情都会导致简单的“工作或失败” ，服务器对您的请求做出的任何更改都会告诉我们一些信息。因此，如果您执行上述任何操作并收到新消息，请不要忘记更新您的问题。

— 绍纳
source

1）对不起，不确定如何做这两个事情。cyberciti.biz/faq/setting-up-an-network-interfaces-file-不确定要添加的IP地址。2）我在原始问题中同时添加了这两个内容。3）我明天看看是否有这个选择（调制解调器等在室友的房间里）。4）尽管至少重启了路由器，但与上述相同。5）尝试了几次。6）我没有ubuntu的另一个comp，但是当我切换到Windows时，这些连接有效。7）尝试过。

— mind.blank 2012年

@ mind.blank您无需在链接中进行任何操作。只需在时钟旁边右键单击网络图标，然后选择“编辑连接...”。单击连接并选择“编辑”，然后选择“ IPv4设置”选项卡，并确保将其设置为“自动（DHCP）”。然后转到“ IPv6设置”选项卡，并确保未选中“需要IPv6寻址才能完成此连接” 。保存并重新连接。如果/当您要关闭IPv6时，请返回“ IPv6设置”选项卡，并将“自动”更改为“忽略”。

— Shauna 2012年

在“网络连接”>“ DSL”>“编辑”中，IPv4设置位于“自动（PPPoE）”上，并且没有IPv6选项卡...

— mind.blank 2012年

2

在实践中我已经两次看到这种行为，为此我找到了以下解决方案。

本地网络中的某台计算机正在成功尝试中间人攻击。这是ARP欺骗网关，从而重定向所有流量以通过此计算机，从而修改请求和其他令人讨厌的内容。该计算机运行Windows，发现感染了一些讨厌的恶意软件。一旦从物理上断开此计算机的连接，症状就会消失。
您或另一个网关上的MTU问题。在IPv4中，如果网关路由流量的网络帧大小不同，则网关负责对网络上的IP数据包进行分段和重组。对于使用PPPoE / PPPoA的DSL连接，MTU大小通常小于LAN端的1500字节。同样，介于两者之间的路由器也会发生故障，您需要在路由器上启用TCP MSS钳制。我一直需要在以前的ISP的连接上进行设置，但它不仅解决了与SSL相关的问题，还解决了更多问题。检查您的调制解调器/路由器是否有这样的选项。认为这是一种解决方法。
我所在的网络可能正在运行透明代理以也传递SSL通信，但是由于某种原因在TLSv1上失败。使用VPN连接时，相同的请求有效。可怕的
尝试运行curl该选项--sslv3。如果解决了，那就发臭了。

可以尝试的常规内容：

检查您的调制解调器/路由器上是否正在运行最新的固件。如果不是，请尝试升级。
使用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有关。

— 格特维季克
source

我已经尝试过使用curl，--sslv3但是仍然无法正常工作。我也试图捕获转储，但似乎不起作用？tcpdump: WARNING: eth0: no IPv4 address assigned 0 packets captured 6 packets received by filter 0 packets dropped by kernel-我不确定如何分配IPv4 ...明天就要休息了，因为天色已晚，我的大脑也无法正常工作。到目前为止，感谢您的帮助！

— mind.blank 2012年

@ mind.blank对您来说，它是ppp0接口，而不是eth0让我想到：为什么在使用路由器时需要PPP进行连接？

— gertvdijk 2012年

正常的“有线”连接未接任何东西。现在，我在问题的底部添加了tcpdump，并提供了有关为什么使用PPPoE的更多详细信息。另外，如果您需要转储中的更多信息，请告诉我。

— mind.blank 2012年

@ mind.blank转储非常有用，但不仅仅是指向解决方案。看到我更新的答案。

— gertvdijk 2012年

0

大家好，我是来自意大利的marcovaleriof，最近我们遇到了一个与您类似的问题：我们的所有Linux机器都无法再连接到任何https网站，而Android或Windows Device都没有问题。问题出在我们的DSL路由器（长度为1492 mtu）和默认的Linux mtu IS 1500之间存在mtu混乱。事实上，以root身份发出此命令

ifconfig wlan0 mtu 1492 up

（用英语设置此网络接口的mtu值-在我的情况下为wlan0-为1492长度）已经解决了这个问题，谢谢！希望这可以帮助某人。

— 马尔科夫列夫
source

-2

感谢您的所有帮助，问题终于得到解决！

我试图限制MTU以查看是否有帮助，并最终使用它pppoeconf来建立PPPoE连接，因为它限制了我的MTU。然后，我禁用了以前使用的DSL连接。

对于遇到类似问题的任何人，您都可以通过键入sudo ppoeconf并按照说明尝试该解决方案。然后，您可以连接pon adsl-provider和断开连接poff

— 思维空白
source