Acabei de me mudar para um novo apartamento e com conexão à Internet por meio de um roteador e estou descobrindo que não consigo me conectar a alguns sites que usam SSL.
Por exemplo, tentando se conectar ao 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 fornece o mesmo resultado.
Para alguns sites, funciona:
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/
.
.
.
Estou usando o Ubuntu 12.04, com o Windows 7 instalado também. Esses sites funcionam no Windows: (
Não tenho certeza se essa informação ajuda, mas eu corri ifconfig e recebi o seguinte:
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)
Eu corri o 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
E sem 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 * * *
sem 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 * * *
O 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
Este é um ISP japonês e, embora eu esteja conectando com um cabo para o modem / roteador, eu preciso adicionar um nome de usuário e senha, mas com a conexão "Wired" do Ubuntu eu não poderia adicionar estes. Minha colega de casa me disse para criar uma conexão OCN, mas não tenho certeza se isso é um nome de um tipo de rede ou apenas da empresa japonesa ... mas depois de olhar para o computador, descobrimos que é uma conexão PPPoE. Depois de algumas pesquisas eu aprendi que para criar uma conexão PPPoE eu precisaria criar uma conexão DSL e que eu poderia adicionar uma senha & amp; nome de usuário para ele. Eu também mudei a conexão "Wired" para não conectar automaticamente.
Eu tenho o mesmo problema se ligar diretamente ao modem.
Eu tentei mudar a MTU do DSL para 500, 1500, 1492 e 1482, mas isso não fez diferença.
Também por alguma razão o Ubuntu nem sempre pega a conexão, eu às vezes tenho que reiniciar para ela se conectar.
Obrigado por toda sua ajuda, o problema está finalmente resolvido!
Eu estava tentando limitar o MTU para ver se ajudaria e acabei usando pppoeconf para configurar a conexão PPPoE, já que limita o MTU para mim. Em seguida, desativei a conexão DSL que eu usei anteriormente.
Para qualquer um que tenha um problema semelhante, você pode tentar essa solução digitando sudo ppoeconf e seguindo as instruções. Então você pode se conectar com pon adsl-provider e desconectar com poff
Esta é uma pergunta antiga, mas para aqueles que estão chegando pelo Google, isso ajudará. O problema é que a fragmentação no SSL é ruim e quebra o protocolo. Se você estiver usando o PPPOE, a MTU normal em seu modem roteador / DSL / Cabo será 1492. Isso é muito alto e causará fragmentação. 1476 é o número mágico que funcionará com a maioria dos sites. Alguns sites usam diferentes implementações SSL, de modo que o 1480 pode funcionar, ou mesmo o 1488. Para a maior compatibilidade, o MTU no lado da WAN do seu dispositivo de rede (roteador, modem, etc.) deve ser 1476.
Aqui estão algumas coisas para experimentar:
Verifique as configurações da sua placa de rede. Nenhuma de suas interfaces de eth está exibindo endereços IPv4. Certifique-se de ter o IPv4 ligado (talvez seja necessário restabelecer sua conexão com o roteador para renovar o IP). Se isso não funcionar, tente desativar o suporte a IPv6 e veja se isso faz diferença. Faça isso clicando com o botão direito do mouse no ícone de rede pelo seu relógio (quando em uma conexão Ethernet, é um par de setas, uma apontando para cima, a outra para baixo) e selecionando "Editar conexões ...". Na guia "Configurações IPv4", verifique se está definido como "Automático (DHCP)". Se você quiser desativar o IPv6, vá até a guia e defina-o como "Ignorar".
Verifique se você pode se conectar aos sites usando outros métodos. Com o que o ping responde para os sites aos quais você não pode se conectar? Que tal um traceroute (você pode ter que instalar o traceroute para usá-lo, FYI)? Suas respostas podem ajudar você a solucionar o problema. Se eles não conseguirem acessar os servidores da URL, talvez seja um problema de DNS (no entanto, se eles conseguirem acessar os servidores da URL, mas forem descartados, isso pode significar que esses comandos estão bloqueados).
Ignore o roteador. Se o seu roteador e o seu modem são duas máquinas diferentes, tente conectar seu computador diretamente ao seu modem e ver se isso muda alguma coisa.
Reinicie o modem e o roteador. Às vezes, eles apenas sugam.
Reinicie o computador. Às vezes, eles apenas são péssimos.
Tente um computador diferente. Se você tiver um, outro computador funciona onde esse falhar? Se não, então pode ser algo com o seu computador específico.
Limpe o cache, os cookies do seu computador, etc. Às vezes, cookies, cache, etc. de sessões ruins podem interferir na conexão com um site (tive esse problema no Google há algum tempo) . Limpe-os e comece de novo e veja o que você recebe.
Desconecte qualquer conexão VPN. O protocolo ponto-a-ponto geralmente é usado para VPN (a interface PPP) e as VPNs podem interferir na conexão com os sites. Certifique-se de que você não está conectado clicando com o botão direito do mouse no ícone da rede pelo relógio, localizando a entrada "Conexões VPN" e certificando-se de que nenhuma listagem esteja marcada (se você não tiver um item de menu "Conexões VPN") t ter um configurado). Se houver alguma verificação, você está conectado a ela, desconecte-a.
Lembre-se: Nem tudo que você faz resultará em um simples "trabalho ou falha", qualquer alteração na reação do servidor ao seu pedido nos dirá algo. Portanto, se você fizer alguma das situações acima e receber uma nova mensagem, não se esqueça de atualizar sua pergunta.
Eu já vi esse comportamento duas vezes na prática para o qual encontrei as seguintes soluções.
curl com a opção --sslv3 . Se isso resolve, então ele fede. Coisas gerais para experimentar:
Capture o tráfego usando tcpdump ou Whireshark e faça a análise (poste aqui, por exemplo).
# 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
Se você estiver recebendo Remontando os erros ou segmento anterior perdido repetidamente, este é um sinal claro sobre a perda de pacotes causada por um tamanho de MTU errado. O tráfego HTTPS é criptografado e difícil de analisar pelo tráfego de rede sozinho.
Editar:
No seu tcpdump, a raiz do problema do SSL é clara: TCP Previous segment lost . A solução de problemas gerais de rede deve ser aplicada aqui, mas pode estar fora do escopo de sua rede local e de um problema com seu ISP.