特定の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  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接続を作成するにはDSL接続を作成する必要があり、パスワードとユーザー名を追加できることを学びました。また、「有線」接続を変更して、自動的に接続しないようにしました。

モデムに直接接続すると、同じ問題が発生します。

DSL MTUを500、1500、1492、1482に変更しようとしましたが、違いはありませんでした。

また、何らかの理由でUbuntuが常に接続を取得するとは限らないため、接続するために再起動する必要がある場合があります。

これは古い質問ですが、Google経由でここにアクセスする人にとっては、これが役立ちます。問題は、SSLでの断片化が不良であり、プロトコルが壊れることです。PPPOEを使用している場合、ルーター/ DSL /ケーブルモデムの通常のMTUは1492です。これは高すぎるため、フラグメンテーションが発生します。1476は、ほとんどのサイトで機能するマジックナンバーです。一部のサイトは異なるSSL実装を使用しているため、1480または1488でも動作します。MOST互換性のために、ネットワークデバイス（ルーター、モデムなど）のWAN側のMTUは1476である必要があります。

試してみることがいくつかあります。

1. ネットワークカードの設定を確認してください。どちらのethインターフェースもIPv4アドレスを表示していません。IPv4がオンになっていることを確認します（IPを更新するには、ルーターとの接続を再確立する必要がある場合があります）。それでもうまくいかない場合は、IPv6サポートをオフにしてみて、違いが生じるかどうかを確認してください。これを行うには、時計の横にあるネットワークアイコンを右クリックし（イーサネット接続の場合は上向き、下向きの矢印のペア）、[接続の編集...]を選択します。[IPv4設定]タブで、[自動（DHCP）]に設定されていることを確認します。IPv6をオフにする場合は、そのタブに移動して「無視」に設定します。

2. 他の方法を使用してサイトに接続できるかどうかを確認してください。ping接続できないサイトに対してはどう反応しますか？どうですかtraceroute（使用するにはtracerouteをインストールする必要があるかもしれません）。それらの応答は、問題のトラブルシューティングに役立つ場合があります。URLのサーバーに到達できない場合は、DNSの問題である可能性があります（ただし、URLのサーバーに到達できるが、その後ドロップされる場合は、単にそれらのコマンドがブロックされることを意味する場合があります）。

3. ルーターをバイパスします。ルーターとモデムが2つの異なるマシンである場合、コンピューターをモデムに直接接続し、それが何かを変更するかどうかを確認してください。

4. モデムとルーターを再起動します。時々、彼らはただ吸います。

5. コンピュータを再起動してください。時々、彼らはただ吸います。

6. 別のコンピューターを試してください。ある場合、別のコンピューターはこのコンピューターで障害が発生しても動作しますか？そうでない場合は、特定のコンピューターに問題がある可能性があります。

7. コンピューターのキャッシュ、Cookieなどをクリアします。時々、不正なセッションCookie、キャッシュなどがサイトへの接続に干渉することがあります（しばらく前にGoogleでこの問題が発生しました）。それらをクリアし、新鮮に始めて、何が得られるかを見てください。

8. VPN接続をすべて切断します。多くの場合、VPN（PPPインターフェース）にはポイントツーポイントプロトコルが使用され、VPNはサイトへの接続に干渉する可能性があります。ネットワークアイコンを時計で右クリックし、「VPN接続」エントリを見つけて、リストがチェックされていないことを確認して、接続されていないことを確認します（「VPN接続」メニュー項目がない場合は、 tは1つ設定されています）。チェックが付いている場合は、接続されており、接続を解除します。

覚えている：あなたはない、すべてがシンプルになります「仕事や失敗し、」すべてのリクエストに対するサーバの反応の変化は、私たちに何かを教えてくれます。したがって、上記のいずれかを実行して新しいメッセージを取得した場合は、質問を更新することを忘れないでください。

この動作は実際に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に問題がある可能性があります。

みなさんこんにちは、イタリア出身です。最近、あなたと同じような問題がありました。Linuxマシンはすべて、https Webサイトに接続できなくなりましたが、AndroidやWindowsデバイスには問題はありませんでした。問題は、長さが1492 mtuのDSLルーターと1500であるデフォルトのLinux mtuの間のmtuの不整合でした。事実、このコマンドをルートとして発行することにより

ifconfig wlan0 mtu 1492 up

（英語では、このセットはネットインターフェースのmtu値-私の場合はwlan0-1492の長さまで）問題を取り除きました、ありがとう！これが誰かを助けることを願っています。

すべてのあなたの助けをありがとう、問題は最終的に修正されました！

私はMTUを制限しようとしたので、MTUが制限pppoeconfされるため、PPPoE接続の設定に役立つかどうかを確認しました。次に、以前使用したDSL接続を無効にしました。

同様の問題が発生した場合は、入力sudo ppoeconfして指示に従うことでこの解決策を試すことができます。次に、で接続pon adsl-providerおよび切断できますpoff