Не вдається підключитися до певних сайтів 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

Це японський Інтернет-провайдер, і хоча я підключаюсь до кабелю до модему / маршрутизатора, мені потрібно додати ім’я користувача та пароль, але за допомогою "дротового" підключення Ubuntu я не зміг їх додати. Моя домогосподарка сказала мені створити з'єднання OCN, але я не впевнений, чи це ім’я типу мережі, чи лише японська компанія ... але, подивившись на її комп'ютер, ми виявили, що це з'єднання PPPoE. Після деякого гуглінгу я дізнався, що для створення PPPoE-зв’язку мені потрібно створити DSL-з'єднання і що я можу додати до нього пароль та ім’я користувача. Я також змінив "Провідне" з'єднання, щоб не підключатися автоматично.

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

Я спробував змінити DSL MTU на 500, 1500, 1492 та 1482, але це не змінило значення.

Крім того, чомусь Ubuntu не завжди підключає з'єднання, мені іноді доводиться перезапускати для його підключення.

Це старе питання, але для тих, хто потрапляє сюди через Google, це допоможе. Проблема полягає в тому, що фрагментація на SSL є поганою і порушує протокол. Якщо ви використовуєте PPPOE, нормальний MTU у вашому модемі маршрутизатора / DSL / Cable становить 1492. Це занадто високо і може спричинити фрагментацію. 1476 - це магічне число, яке буде працювати з більшістю сайтів. Деякі сайти використовують різні реалізації SSL, тому 1480 може працювати, або навіть 1488. Для МОСТО сумісності MTU на стороні WAN вашого мережевого пристрою (маршрутизатор, модем тощо) має становити 1476.

Ось кілька речей, які можна спробувати:

1. Перевірте настройки вашої мережевої карти. Ні в одному з ваших інтерфейсів не відображаються адреси IPv4. Переконайтеся, що у вас увімкнено IPv4 (можливо, вам потрібно буде відновити зв’язок із маршрутизатором, щоб відновити IP-адресу). Якщо це не працює, спробуйте вимкнути підтримку IPv6 і побачити, чи це має значення. Зробіть це, клацнувши правою кнопкою миші піктограму мережі (коли підключення до Ethernet - це пара стрілок, одна спрямована вгору, а друга вниз) та виберіть "Змінити підключення ...". На вкладці "Налаштування IPv4" переконайтесь, що встановлено значення "Автоматично (DHCP)". Якщо ви хочете вимкнути IPv6, перейдіть на його вкладку та встановіть його на "Ігнорувати".

2. Перевірте, чи можете ви підключитися до сайтів іншими методами. Що pingвідповідає за сайти, до яких ви не можете підключитися? Як щодо traceroute(можливо, вам доведеться встановити traceroute, щоб використовувати його, FYI)? Їхні відповіді можуть допомогти вирішити проблему. Якщо вони не зможуть дістатися до серверів URL-адреси, це може бути проблема DNS (однак, якщо вони можуть потрапити на сервери URL-адреси, але потім їх скидають, це може означати, що ці команди заблоковані).

3. Обхід маршрутизатора. Якщо ваш маршрутизатор і ваш модем - це дві різні машини, спробуйте підключити комп’ютер безпосередньо до модему і побачити, чи це щось змінить.

4. Перезавантажте модем та маршрутизатор. Іноді вони просто смокчуть.

5. Перезавантажте комп'ютер. Іноді вони просто смокчуть.

6. Спробуйте інший комп’ютер. Якщо у вас є, чи працює інший комп'ютер там, де цей не працює? Якщо ні, то це може бути щось із вашим конкретним комп'ютером.

7. Очистіть кеш-пам'ять комп'ютера, файли cookie тощо. Іноді файли cookie, кеш-пам’яті поганого сеансу можуть перешкоджати підключенню до веб-сайту (у мене ця проблема була в Google раніше). Очистіть їх і почніть свіжий і подивіться, що ви отримаєте.

8. Від'єднайте всі VPN-з'єднання. Протокол "точка-точка" часто використовується для VPN (інтерфейс PPP), і VPN можуть перешкоджати підключенню до сайтів. Переконайтеся, що ви не з’єднані, натиснувши правою кнопкою миші піктограму мережі, знайдіть запис "VPN Connections" і переконайтесь, що не вказано лістинг (якщо у вас немає пункту меню "VPN Connections", тоді ви не робите " у вас є одна настройка). Якщо є перевірені, ви підключитесь до нього, відключіться від нього.

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

Я бачив таку поведінку двічі на практиці, для чого я знайшов такі рішення.

• Деякий комп’ютер у локальній мережі успішно намагався здійснити атаку людини. ARP-підробляє шлюз, тим самим перенаправляючи весь трафік, щоб пройти через цю машину, змінивши запити та інші неприємні речі. Машина працює під управлінням Windows і виявила, що заражена шкідливим шкідливим програмним забезпеченням. Як тільки цю машину фізично відключили від мережі, симптоми зникли.
• Проблема MTU на ваш або іншої шлюз. У шлюзах IPv4 відповідальні за фрагментацію та повторну збірку IP-пакетів у мережі, якщо розмір кадру мереж, для яких здійснюється маршрутизація, не однаковий. Для підключень DSL, що використовують PPPoE / PPPoA, розмір MTU зазвичай менший, ніж 1500 байт на стороні локальної мережі. Також маршрутизатори між помилками і вам потрібно включити затискання TCP MSS на маршрутизаторі. Мені завжди потрібно було встановити це на підключенні мого попереднього провайдера, але це вирішувало більше, ніж лише проблеми, пов’язані з 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. Тут слід застосувати загальне усунення несправностей у мережі, але це може бути поза межами вашої локальної мережі та проблема з вашим провайдером.

Привіт усім, це IS marcovaleriof з Італії, нещодавно у нас виникла проблема, схожа на вашу: вся наша Linux машина не могла більше підключитися до будь-якого веб-сайту https, тоді як Android або Windows Device не мали жодних проблем. Проблема полягала в невідповідності між нашим маршрутизатором DSL, який мав довжину 1492 mtu, і Linux mtu за замовчуванням IS 1500. Що стосується фактів, що видають цю команду як root

ifconfig wlan0 mtu 1492 up

(англійською мовою цей набір Значення net-інтерфейсу - wlan0 в моєму випадку - довжина 1492) позбулося проблеми, дякую! Сподіваюся, це може комусь допомогти.

Дякуємо за всю вашу допомогу, проблема остаточно виправлена!

Я намагався обмежити MTU, щоб побачити, чи допоможе це, і в кінцевому підсумку використовувався pppoeconfдля налаштування PPPoE-з'єднання, оскільки він обмежує MTU для мене. Потім я відключив з'єднання DSL, яке раніше використовував.

Для тих, хто має подібну проблему, ви можете спробувати це рішення, ввівши sudo ppoeconfта дотримуючись інструкцій. Тоді ви зможете підключитися pon adsl-providerі відключитисяpoff