Не удается подключиться к определенным HTTPS-сайтам

12

Я только что переехал в новую квартиру с подключением к Интернету через роутер и обнаружил, что не могу подключиться к нескольким сайтам, использующим 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 не всегда устанавливает соединение, мне иногда приходится перезапускать его, чтобы подключиться.

mind.blank
источник
эти сайты открываются не только в curlдругих браузерах?
adempewolff
Они вообще не открываются, я просто пытался выяснить, в чем проблема ...
mind.blank
@ mind.blank - Что дает вам браузер при попытке подключения? Если вы ничего не получаете из главного окна, попробуйте установить Firebug (если вы используете Firefox; если вы используете Chrome, в него встроены инструменты разработчика), откройте его, активируйте вкладки консоли и сети и посмотрите, есть ли любые ошибки, а затем сообщить о них здесь.
Шона
Вы пользовались роутером раньше или он новый? Кроме того, вы не сделали ничего глупого и не обновили ваши пакеты ssl или что-либо из установки по умолчанию? Я получаю доступ ко всем этим сайтам нормально (ну, по крайней мере, через мой прокси, в противном случае Китай случайно блокирует протокол ssl), поэтому я предполагаю, что проблема заключается либо в маршрутизаторе, либо в обновленном / установленном пакете.
adempewolff
@Shauna Я использую Chrome, и это говорит Error 7 (net::ERR_TIMED_OUT): The operation timed out. FireFox просто пытается загрузить, но никогда не делает (страница не меняется). Консоль и Сеть ничего мне не дают ...
mind.blank

Ответы:

11

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

regretoverflow
источник
1
Я не вижу, как фрагментация сломает SSL. Фрагментированные пакеты будут повторно собраны маршрутизаторами в IPv4. SSL происходит поверх TCP, на уровне, где вы не должны этого замечать. Я думаю, что это связано со значениями MTU, но я не думаю, что ваше объяснение подходит. Я думаю, что это связано с настройками MTU, которые не синхронизированы на обоих концах, что приводит к неправильной повторной сборке фрагментированных пакетов. Магическое число может работать в вашем случае, но не для других.
gertvdijk
Бит DF (Dont Fragment) всегда устанавливается в трафике SSL специально - фрагментация является дырой в безопасности. Фрагментированный пакет SSL будет отброшен в 99,9% случаев. Слишком низкий MTU для трафика PPoE приведет к фрагментации.
regretoverflow
Это случилось со мной на сайте PayPal. Я пытался рассчитаться с MTU 1476 и не работал, но с 1480 работал. Спасибо!
игривый
Я потратил 6 часов утра до 2 вечера, пытаясь решить эту проблему, пока не нашел ваш ответ. Очень признателен!
WayBehind
1
святая корова! Это позволило мне sudo yum install docker-engineпосле добавления репозитория yum.dockerproject.org в систему CentOS 7: sudo ip link set mtu 1476 dev enp6s0снизить MTU со значения по умолчанию с 1500 до 1476. В течение дня я ломал голову, пытаясь понять, почему был доступен yum.dockerproject.org. через https от других узлов в той же сети.
JWD630
3

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

  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-подключения», значит, вы не иметь одну настройку). Если есть какие-либо проверенные, то вы подключены к нему, отключиться от него.

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

Shauna
источник
1) Извините, не уверен, как сделать обе эти вещи. cyberciti.biz/faq/setting-up-an-network-interfaces-file - не уверен, какие IP-адреса добавить. 2) Я добавил оба из них в исходном вопросе. 3) Я посмотрю, есть ли у меня такая опция завтра (модем и т. Д. В комнате соседей). 4) То же, что и выше, хотя я перезапустил маршрутизатор по крайней мере. 5) Пробовал несколько раз. 6) У меня нет другого компа с Ubuntu, однако эти соединения работают, когда я переключаюсь на Windows. 7) Попробовал это.
mind.blank
@ mind.blank Вам не нужно ничего делать в ссылке. Просто щелкните правой кнопкой мыши значок сети по часам и выберите «Редактировать подключения ...». Нажмите на соединение и выберите «Изменить», затем перейдите на вкладку «Настройки IPv4» и убедитесь, что установлено «Автоматически (DHCP)». Затем перейдите на вкладку «Настройки IPv6» и убедитесь, что «Требуется IPv6-адресация для завершения этого соединения» не отмечена. Сохраните и переподключите. Если / когда вы хотите отключить IPv6, вернитесь на вкладку «Настройки IPv6» и измените «Автоматически» на «Игнорировать».
Шона
В разделе «Сетевые подключения»> «DSL»> «Редактировать» настройки IPv4 установлены на «Автоматически (PPPoE)», а вкладка IPv6 отсутствует ...
mind.blank
2

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

  • На каком-то компьютере в локальной сети была предпринята попытка атаки «человек посередине». Это был 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. Здесь должно применяться общее устранение неполадок в сети, но это может выходить за рамки вашей локальной сети и проблемы с вашим провайдером.

gertvdijk
источник
Я пытался запустить 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
@ mind.blank Для вас это ppp0интерфейс, а не eth0заставляет меня задуматься: зачем вам PPP для соединения при использовании роутера?
gertvdijk
Обычное «проводное» соединение ничего не обнаруживало. Теперь я добавил tcpdump внизу моего вопроса с более подробной информацией о том, почему я использую PPPoE. Также, если вам нужна дополнительная информация из свалки, пожалуйста, сообщите мне.
mind.blank
@ mind.blank Дамп очень полезен, но не просто указывает на решение. Смотрите мой обновленный ответ.
gertvdijk
0

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

ifconfig wlan0 mtu 1492 up

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

marcovaleriof
источник
-2

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

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

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

mind.blank
источник