Не удается подключиться к определенным 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:

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

Это японский интернет-провайдер, и хотя я подключаюсь с помощью кабеля к модему / маршрутизатору, мне нужно добавить имя пользователя и пароль, но с помощью «проводного» подключения Ubuntu я не смог их добавить. Моя соседка сказала мне создать соединение OCN, но я не уверен, является ли это именем типа сети или просто японской компанией ... но, посмотрев на ее компьютер, мы обнаружили, что это соединение PPPoE. После некоторого поиска в Google я узнал, что для создания PPPoE-соединения мне нужно создать DSL-соединение и что я могу добавить к нему пароль и имя пользователя. Я также изменил «Проводное» соединение, чтобы не подключаться автоматически.

У меня та же проблема, если я подключаюсь к модему напрямую.

Я пытался изменить DSL MTU на 500, 1500, 1492 и 1482, но это не имело значения.

Также по какой-то причине Ubuntu не всегда устанавливает соединение, мне иногда приходится перезапускать его, чтобы подключиться.

Это старый вопрос, но для тех, кто попадает сюда через Google, это поможет. Проблема в том, что фрагментация по протоколу SSL является плохой и нарушает протокол. Если вы используете PPPOE, обычный MTU в маршрутизаторе / DSL / кабельном модеме равен 1492. Это слишком высокое значение и приведет к фрагментации. 1476 - это магическое число, которое будет работать с большинством сайтов. Некоторые сайты используют разные реализации SSL, поэтому может работать 1480 или даже 1488. Для совместимости с MOST значение MTU на стороне WAN вашего сетевого устройства (маршрутизатор, модем и т. Д.) Должно быть 1476.

Вот пара вещей, чтобы попробовать:

1. Проверьте настройки вашей сетевой карты. Ни один из ваших интерфейсов eth не показывает адреса IPv4. Убедитесь, что у вас включен IPv4 (вам может потребоваться восстановить соединение с маршрутизатором, чтобы обновить IP). Если это не сработает, попробуйте отключить поддержку IPv6 и посмотреть, имеет ли это значение. Сделайте это, щелкнув правой кнопкой мыши значок сети на часах (при подключении к сети Ethernet это пара стрелок, одна направлена ​​вверх, а другая вниз) и выбрав «Редактировать соединения ...». На вкладке «Настройки IPv4» убедитесь, что установлено «Автоматически (DHCP)». Если вы хотите отключить IPv6, перейдите на его вкладку и установите для него значение «Игнорировать».

2. Проверьте, можете ли вы подключиться к сайтам другими способами. Что pingотвечает за сайты, к которым вы не можете подключиться? Как насчет traceroute(вам может понадобиться установить traceroute, чтобы использовать его, к вашему сведению)? Их ответы могут помочь вам решить проблему. Если они не могут получить доступ к серверам URL, это может быть проблемой DNS (однако, если они могут получить доступ к серверам URL, но затем их отбрасывают, это может означать, что эти команды заблокированы).

3. Обойти роутер. Если ваш маршрутизатор и ваш модем - две разные машины, попробуйте подключить ваш компьютер напрямую к модему и посмотреть, изменит ли это что-нибудь.

4. Перезагрузите модем и роутер. Иногда они просто сосут.

5. Перезагрузите компьютер. Иногда они просто сосут.

6. Попробуйте другой компьютер. Если у вас есть один, другой компьютер работает, где этот отказывает? Если нет, то это может быть что-то с вашим конкретным компьютером.

7. Очистите кэш вашего компьютера, файлы cookie и т. Д. Иногда файлы cookie, кэш и т. Д. Сбоев могут мешать подключению к сайту (у меня эта проблема была с Google некоторое время назад). Очистите их и начните все сначала и посмотрите, что вы получите.

8. Отключите все VPN-соединения. Протокол «точка-точка» часто используется для VPN (интерфейс PPP), и VPN могут мешать подключению к сайтам. Убедитесь, что вы не подключены, щелкнув правой кнопкой мыши значок сети по часам, найдя запись «VPN-подключения» и убедившись, что список не проверен (если у вас нет пункта меню «VPN-подключения», значит, вы не иметь одну настройку). Если есть какие-либо проверенные, то вы подключены к нему, отключиться от него.

Помните: не все, что вы делаете, приведет к простой «работе или неудаче», любое изменение в реакции сервера на ваш запрос нам что-то скажет. Так что, если вы делаете что-либо из вышеперечисленного и получаете новое сообщение, не забудьте обновить свой вопрос.

Я видел такое поведение дважды на практике, для которого я нашел следующие решения.

• На каком-то компьютере в локальной сети была предпринята попытка атаки «человек посередине». Это был ARP-спуфинг шлюза, таким образом перенаправляя весь трафик для прохождения через эту машину, изменяя запросы и другие неприятные вещи. Машина работала под управлением Windows и была обнаружена зараженной вредоносной программой. Как только эта машина была физически отключена от сети, симптомы исчезли.
• Проблема MTU на ваш или другой шлюз. В IPv4 шлюзы отвечают за фрагментацию и повторную сборку IP-пакетов в сети, если размер кадра сетей, для которых маршрутизируется трафик, не одинаков. Для соединений DSL, использующих PPPoE / PPPoA, размер MTU обычно меньше 1500 байт на стороне локальной сети. Также между маршрутизаторами происходит сбой, и вам необходимо включить TCP MSS Clamping на вашем маршрутизаторе. Мне всегда нужно было устанавливать это при подключении моего предыдущего интернет-провайдера, но это решало не только проблемы, связанные с 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 зашифрован и его трудно анализировать из сетевого трафика.

Редактировать:

Из вашего ТСРйитра корень вашей проблемы SSL ясен: TCP Previous segment lost. Здесь должно применяться общее устранение неполадок в сети, но это может выходить за рамки вашей локальной сети и проблемы с вашим провайдером.

Привет всем! Это marcaleriof из Италии, недавно у нас была проблема, похожая на вашу: все наши Linux-машины больше не могли подключаться к любому веб-сайту https, в то время как Android или Windows Device не имели проблем. Проблема заключалась в смещении mtu между нашим DSL-маршрутизатором, который имел длину 1492 mtu, и Linux mtu по умолчанию, равным 1500. Фактически, эта команда была выполнена от имени root

ifconfig wlan0 mtu 1492 up

(на английском языке этот набор Значение mtu сетевого интерфейса - wlan0 в моем случае - до длины 1492) избавило от проблемы, спасибо! Надеюсь, это может кому-то помочь.

Спасибо за вашу помощь, проблема наконец-то решена!

Я пытался ограничить MTU, чтобы посмотреть, поможет ли он, и в итоге использовал pppoeconfдля настройки PPPoE-соединение, поскольку это ограничивает MTU для меня. Затем я отключил соединение DSL, которое я ранее использовал.

Если вы столкнулись с подобной проблемой, вы можете попробовать это решение, набрав sudo ppoeconfи следуя инструкциям. Затем вы можете подключиться pon adsl-providerи отключиться сpoff