Não é possível conectar-se a determinados sites HTTPS

12

Acabei de me mudar para um apartamento novo 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 dá a mesma saída.

Para alguns sites, ele 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 essas informações ajudam, mas eu executei ifconfige obtive 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 executei 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, apesar de estar conectado a um cabo ao modem / roteador, preciso adicionar um nome de usuário e uma senha, mas com a conexão "com fio" do Ubuntu não consegui adicioná-los. Minha colega de casa me disse para criar uma conexão OCN, mas não tenho certeza se esse é o nome de um tipo de rede ou apenas a empresa japonesa ... mas depois de olhar para o computador dela, descobrimos que era uma conexão PPPoE. Depois de pesquisar no Google, aprendi que, para criar uma conexão PPPoE, seria necessário criar uma conexão DSL e que eu poderia adicionar uma senha e nome de usuário. Também mudei a conexão "Com fio" para não conectar automaticamente.

O mesmo problema ocorre se eu conectar diretamente ao modem.

Tentei mudar o DSL MTU para 500, 1500, 1492 e 1482, mas não fez diferença.

Também por alguma razão, o Ubuntu nem sempre capta a conexão, às vezes tenho que reiniciar para conectar.

mind.blank
fonte
esses sites não estão abrindo apenas com curlou não estão abrindo com outros navegadores também?
adempewolff
Eles não estão abrindo em tudo, eu estava apenas tentando descobrir onde está o problema ...
mind.blank
@ mind.blank - O que o navegador oferece quando você tenta se conectar? Se você não obtiver nada da janela principal, tente instalar o Firebug (se você usa o Firefox; se você usa o Chrome, ele possui as ferramentas de desenvolvedor integradas), abra-o, ative o console e as guias de rede e veja se há erros, relate-os aqui.
Shauna
Você estava usando o roteador antes ou é novo? Além disso, você não fez nada bobo e atualizou seus pacotes ssl ou algo de uma instalação padrão? Estou acessando bem todos esses sites (pelo menos através do meu proxy, a China bloqueia aleatoriamente o protocolo SSL), então acho que o problema está no roteador ou em um pacote atualizado / instalado.
adempewolff
@ Shauna Estou usando o Chrome e está dizendo Error 7 (net::ERR_TIMED_OUT): The operation timed out. O FireFox continua tentando carregar, mas nunca carrega (a página não muda). Console e rede não me dão nada ...
mind.blank

Respostas:

11

Esta é uma pergunta antiga, mas para quem chega aqui pelo Google, isso ajudará. O problema é que a fragmentação no SSL é ruim e quebra o protocolo. Se você estiver usando PPPOE, a MTU normal no seu roteador / DSL / modem a cabo é 1492. Isso é muito alto e causa fragmentação. 1476 é o número mágico que funcionará com a maioria dos sites. Alguns sites usam implementações SSL diferentes para que o 1480 funcione, ou até o 1488. Para compatibilidade MOST, o MTU no lado WAN do seu dispositivo de rede (roteador, modem, etc) deve ser 1476.

regretoverflow
fonte
1
Não vejo como a fragmentação quebrará o SSL. Pacotes fragmentados serão remontados por roteadores no IPv4. O SSL acontece no topo do TCP, em um nível em que você não deve perceber isso. Eu acho que isso tem a ver com os valores da MTU, mas não acho que sua explicação se qualifique. Eu acho que tem a ver com as configurações da MTU que não estão sincronizadas nas duas extremidades, resultando na remontagem incorreta de pacotes fragmentados. O número mágico pode funcionar no seu caso, mas não para outros.
gertvdijk
O bit DF (Dont Fragment) é sempre definido no tráfego SSL por design - a fragmentação é uma falha de segurança. Um pacote SSL fragmentado será descartado 99,9% das vezes. Um MTU muito baixo no tráfego PPoE causará fragmentação.
regretoverflow
Isso aconteceu comigo no site do PayPal. Tentei me estabelecer com o MTU 1476 e não funcionou, mas com o 1480 funcionou. Obrigado!
brincalhão
Passei das 6h às 14h tentando resolver isso até encontrar sua resposta. Muito apreciado!
WayBehind
1
vaca sagrada! Isso me permitiu sudo yum install docker-enginedepois de adicionar o repositório yum.dockerproject.org em uma caixa do CentOS 7: sudo ip link set mtu 1476 dev enp6s0diminuir o MTU do padrão de 1500 para 1476. Estive coçando a cabeça durante um dia tentando descobrir por que o yum.dockerproject.org estava acessível via https de outros nós na mesma rede.
jwd630
3

Aqui estão algumas coisas para tentar:

  1. Verifique as configurações da sua placa de rede. Nenhuma das suas interfaces eth está mostrando endereços IPv4. Verifique se o IPv4 está ativado (pode ser necessário restabelecer sua conexão com o roteador para renovar o IP). Se isso não funcionar, tente desativar o suporte ao IPv6 e veja se isso faz diferença. Faça isso clicando com o botão direito do mouse no ícone de rede do relógio (quando estiver em uma conexão Ethernet, é um par de setas, uma apontando para cima e outra para baixo) e selecionando "Editar conexões ...". Na guia "Configurações IPv4", verifique se está definido como "Automático (DHCP)". Se você deseja desativar o IPv6, vá para a guia e defina-o como "Ignorar".

  2. Verifique se você pode se conectar aos sites usando outros métodos. O que pingresponde aos sites aos quais você não pode se conectar? Que tal um traceroute(pode ser necessário instalar o traceroute para usá-lo, FYI)? Suas respostas podem ajudá-lo a solucionar o problema. Se eles não conseguirem acessar os servidores da URL, pode ser um problema de DNS (no entanto, se eles puderem acessar os servidores da URL, mas forem descartados, isso pode significar apenas que esses comandos estão bloqueados).

  3. Ignore o roteador. Se o seu roteador e o modem são duas máquinas diferentes, tente conectar o computador diretamente ao modem e verificar se isso muda alguma coisa.

  4. Reinicie seu modem e roteador. Às vezes, eles simplesmente são péssimos.

  5. Reinicie o seu computador. Às vezes, eles simplesmente são péssimos.

  6. Tente um computador diferente. Se você tiver um, outro computador funciona onde este falha? Caso contrário, pode ser algo com o seu computador específico.

  7. Limpe o cache, os cookies do computador, etc. Às vezes, os cookies, as sessões ruins de cache, etc., podem interferir na conexão com um site (tive esse problema com o Google há algum tempo). Limpe-os e comece do zero e veja o que você recebe.

  8. Desconecte todas as conexões VPN. O protocolo ponto a ponto é frequentemente usado para VPN (a interface PPP), e as VPNs podem interferir na conexão com sites. Verifique se você não está conectado clicando com o botão direito do mouse no ícone da rede, encontrando a entrada "VPN Connections" e certificando-se de que nenhuma listagem esteja marcada (se você não tiver um item de menu "VPN Connections"), não precisará não tem um configurado). Se houver algum verificado, você está conectado a ele, desconecte-o.

Lembre-se: nem tudo o que você faz resultará em um simples "trabalho ou falha", qualquer alteração na reação do servidor à sua solicitação nos dirá algo. Portanto, se você fizer alguma das perguntas acima e receber uma nova mensagem, não se esqueça de atualizar sua pergunta.

Shauna
fonte
1) Desculpe, não sei como fazer as duas coisas. cyberciti.biz/faq/setting-up-an-network-interfaces-file - não sabe quais endereços IP adicionar. 2) Adicionei os dois na pergunta original. 3) Vou ver se tenho essa opção amanhã (modem etc. está na sala do roomate). 4) O mesmo que acima, embora eu tenha reiniciado o roteador pelo menos. 5) Tentei algumas vezes. 6) Não tenho outro comp com o ubuntu, essas conexões funcionam no entanto quando mudo para o Windows. 7) Tentei isso.
mind.blank
@ mind.blank Você não precisa fazer nada do tipo no link. Simplesmente clique com o botão direito do mouse no ícone da rede e selecione "Editar conexões ...". Clique na conexão e selecione "Editar", selecione a guia "Configurações IPv4" e verifique se está definido como "Automático (DHCP)". Em seguida, vá para a guia "Configurações do IPv6" e verifique se "Requer o endereçamento IPv6 para que esta conexão seja concluída" está desmarcado . Salve e reconecte. Se / quando desejar desativar o IPv6, volte à guia Configurações do IPv6 e altere "Automático" para "Ignorar".
Shauna
Em Conexões de Rede> DSL> Editar configurações IPv4 estão em "Automatic (PPPoE)" e não há guia IPv6 ...
mind.blank
2

Eu já vi esse comportamento duas vezes na prática, para o qual encontrei as seguintes soluções.

  • Algum computador na rede local estava tentando com sucesso um ataque man-in-the-middle. Foi falsificação de ARP no gateway, redirecionando assim todo o tráfego para passar por esta máquina, modificando solicitações e outras coisas desagradáveis. A máquina estava executando o Windows e foi infectada por algum malware desagradável. Assim que essa máquina foi desconectada da rede fisicamente, os sintomas desapareceram.
  • Um problema de MTU no seu ou em outro gateway. Nos gateways IPv4, é responsável por fragmentar e remontar pacotes IP na rede se o tamanho do quadro das redes para as quais o tráfego de roteamento não for o mesmo. Para conexões DSL usando PPPoE / PPPoA, o tamanho da MTU geralmente é menor que os 1500 bytes no lado da LAN. Os roteadores também falham e é necessário ativar o TCP MSS Clamping no seu roteador. Eu sempre precisei definir isso na conexão do meu ISP anterior, mas estava resolvendo mais do que apenas problemas relacionados ao SSL. Verifique se o seu modem / roteador tem essa opção. Considere isso como uma solução alternativa.
  • Eu estava em uma rede provavelmente executando um proxy transparente para também transmitir tráfego SSL, mas falhando no TLSv1 por algum motivo. A mesma solicitação funcionou ao usar uma conexão VPN. assustador
    tente executar curlcom a opção --sslv3. Se isso resolve, então fede.

Coisas gerais para experimentar:

  • Verifique se você está executando o firmware mais recente no seu modem / roteador. Caso contrário, tente atualizar.
  • Capture o tráfego usando tcpdumpou Whireshark e faça a análise (publique 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 perdendo repetidamente erros de remontagem ou segmento anterior , esse é um sinal claro da perda de pacotes causada por um tamanho de MTU errado.
    No entanto, o tráfego HTTPS é criptografado e difícil de analisar por si só.

Editar:

A partir do seu tcpdump a raiz de seu problema SSL é clara: TCP Previous segment lost. A solução geral de problemas de rede deve ser aplicada aqui, mas pode estar fora do escopo da sua rede local e ser um problema com o seu ISP.

gertvdijk
fonte
Eu tentei rodar o curl --sslv3e ainda não funciona. Também tentei capturar o despejo, mas ele não parece estar funcionando? tcpdump: WARNING: eth0: no IPv4 address assigned 0 packets captured 6 packets received by filter 0 packets dropped by kernel- Não sei bem como atribuir o IPv4 ... terei que tentar o resto amanhã, pois está ficando tarde e meu cérebro não está funcionando bem. Obrigado por sua ajuda a todos até agora!
mind.blank
@ mind.blank Para você, é a ppp0interface e não o eth0que me faz pensar: Por que você precisa de PPP para uma conexão ao usar um roteador?
gertvdijk
A conexão "com fio" normal não captou nada. Agora adicionei o tcpdump na parte inferior da minha pergunta com mais alguns detalhes sobre por que estou usando PPPoE. Além disso, se você precisar de mais informações do despejo, me diga.
mind.blank
@ mind.blank O dump é muito útil, mas não aponta apenas para uma solução. Veja minha resposta atualizada.
gertvdijk
0

Olá pessoal, este é o certificado internacional da Itália, recentemente tivemos um problema semelhante ao seu: toda a nossa máquina Linux não conseguia mais se conectar a qualquer site https enquanto o dispositivo Android ou Windows não apresentava problemas. O problema foi um desalinhamento de mtu entre nosso roteador DSL, que tinha um comprimento de 1492 mtu e o mtu padrão do Linux, que é 1500. Por uma questão de fato, este comando foi emitido como root

ifconfig wlan0 mtu 1492 up

(em inglês, este conjunto O valor mtu da interface da rede - wlan0 no meu caso - com 1492 de comprimento) se livrou do problema, obrigado! Espero que isso possa ajudar alguém.

marcovaleriof
fonte
-2

Obrigado por toda a sua ajuda, o problema foi finalmente resolvido!

Eu estava tentando limitar o MTU para ver se isso ajudaria e acabei usando pppoeconfpara configurar a conexão PPPoE, pois limita o MTU para mim. Desativei a conexão DSL usada anteriormente.

Para qualquer pessoa com um problema semelhante, tente esta solução digitando sudo ppoeconfe seguindo as instruções. Então você pode conectar pon adsl-providere desconectar compoff

mind.blank
fonte