it-swarm-korea.com

공개 핫스팟에서 HTTPS 웹 사이트를 방문하는 것이 안전합니까?

서버와 나와의 통신이 암호화되어 서버 인증을 제공하기 때문에 HTTPS SSL/TLS 연결이 암호화되어 안전하다고 말합니다. 이론의 힘.

내가 공용 Wi-Fi를 사용하고 있고 동일한 Wi-Fi에 악의적 인 사용자가 모든 패킷을 스니핑한다고 가정 해 봅시다. 이제이 Wi-Fi를 사용하여 내 Gmail 계정에 액세스하려고한다고 가정하겠습니다. 브라우저가 서버와 SSL/TLS 핸드 셰이크를 수행하고 암호화 및 암호 해독에 사용할 키를 얻습니다.

악의적 인 사용자가 들어오고 나가는 패킷을 모두 스니핑 한 경우. 그는 같은 키를 계산하고 암호화 된 트래픽을 읽거나 암호화 된 메시지를 내 이름으로 서버에 보낼 수 있습니까?

148
Calmarius

HTTPS는 퍼블릭 핫스팟을 통해 안전합니다. HTTPS에서 사용하는 보안 계층 ​​인 TLS 을 설정하는 동안 공개 키와 암호화 된 메시지 만 전송되며 루트 인증서로 서명됩니다. 클라이언트는 공개 키를 사용하여 마스터 비밀을 암호화 한 다음 서버는 개인 키로 해독합니다. 모든 데이터는 각면에서 생성 된 마스터 시크릿과 의사 난수를 사용하는 기능으로 암호화됩니다.

그러므로,

  • 데이터는 마스터 비밀 번호와 의사 난수로 서명되므로 안전합니다.
  • 마스터 비밀 번호와 의사 난수는 TLS 핸드 셰이크가 발생할 때 공개-개인 키 암호화를 사용하므로 안전합니다.
  • 공개-개인 키 암호화는 다음과 같은 이유로 안전합니다.
    • 개인 키는 비밀로 유지됩니다
    • 공개-개인 키 암호화는 개인 키 없이는 사용할 수 없도록 설계되었습니다
    • 공개 키는 루트 인증서로 서명 되었기 때문에 합법적 인 것으로 알려져 있습니다.
    • 컴퓨터와 함께 제공
    • 또는 귀하가 특별히 승인 한 경우 (브라우저 경고에주의하십시오!)

따라서 다음과 같은 경우 HTTPS 연결 및 데이터는 안전합니다.

  1. 컴퓨터와 함께 제공된 인증서를 신뢰하고
  2. 신뢰하는 인증서 만 승인하도록주의를 기울입니다.
109
waiwai933

짧은 대답 : 그것은 달려 있습니다.

SSL/TLS 자체는 일반 인터넷 연결보다 "일반"인터넷보다 더 취약하지 않습니다. 개방형 채널에서 사용하도록 설계되었습니다.

그러나 고려해야 할 몇 가지 다른 측면이 있습니다.

  • 종종 사용자는 HTTPS 사이트를 직접 탐색하지 않고 HTTP 사이트에서 시작하여 리디렉션합니다. 예를 들어 http://example.org/를 찾아 Email 링크를 클릭하면 https://mail.example.org/로 리디렉션됩니다. 원본 HTTP 페이지는 암호화되지 않으므로 악의적 인 사용자가 트래픽을 수정하여 Email 링크가 HTTPS로 리디렉션되지 않고 다른 곳으로 리디렉션 될 수 있습니다. 예를 들어 example.org의 홈페이지에서 Email 링크를 클릭하면 http://mail.exxxample.org/로 연결되었음을 알 수 있습니까? (예로서). 당신 은, 다른 사람은 그렇지 않을 수도 있습니다.
  • 사용자가 연결을 도용했지만 example.org 대신 자체 SSL 인증서를 제공하는 경우 브라우저 will 오류가 표시되면 인증서가 유효하지 않은 것입니다. 그러나 대부분의 사용자는 이것을 클릭하면 공격자가 SSL을 통해 보안 사이트로 MITM을 허용 할 수 있습니다.
  • 고려해야 할 또 다른 측면은 공개 핫스팟이 안전하게 구성되어 있다고 가정하지 마십시오. 이 질문이 표시 함 으로, pwned 라우터는 너무 일반적이며 SSL과 관련이없는 더 많은 손상을 일으킬 수 있습니다.
48
AviD

브라우저를 통한 모든 요청과 서버가 전송 한 페이지가 암호화되므로 완전히 HTTPS를 통한 세션은 상당히 안전합니다.

그러나 HTTPS를 통해 액세스하면 많은 사이트에서 HTTPS를 통한 인증 단계 만 수행 한 다음 나머지 세션 동안 HTTP로 되돌립니다. 따라서 비밀번호 자체는 안전하지만 서버가 해당 세션에 대해 사용자를 식별하기 위해 사용하는 세션 ID는 브라우저에서 명확하게 전송됩니다. 이렇게하면 암호화/암호 해독이 CPU를 많이 사용하기 때문에 웹 서버의 부하가 줄어들지 만 사이트의 보안 수준은 훨씬 낮아집니다. Gmail은 전체 세션에 HTTPS를 사용하기 때문에 안전하지만 Facebook 및 기타 여러 사이트는 그렇지 않습니다.

공격자가 암호화되지 않은 무선 네트워크를 공유 할 때 Firesheep 와 같은 도구가 사용자 계정을 가로 챌 수있는 방법입니다.

VPN을 사용하여 모든 세션 데이터를 암호화하거나 WPA-PSK와 같이 강력한 사용자 별 암호화가있는 네트워크 만 사용하여이 공격으로부터 자신을 보호 할 수 있습니다 (WEP는 모든 사용자에 대해 동일한 키를 사용하므로 그렇지 않습니다) 이 공격으로부터 보호하십시오).

22
Alex Howell

답변이 모든 곳에서 온 것처럼 보이므로 (예, 아니오,있을 수도 있고 있어야합니다) @ waiwai933의 답변을 다시 반복하겠습니다.

구체적으로, "악의적 인 사용자가 들어오고 나가는 패킷을 모두 스니핑 한 경우 같은 키를 계산하고 암호화 된 트래픽을 읽거나 암호화 된 메시지를 내 이름으로 서버에 보낼 수 있습니까?" 대답은 '아니요'입니다. 각주와 함께.

그가 같은 키를 계산할 수없는 이유는 역설적 인 것으로 보이며 실제로 Diffie와 Hellman이 처음 출판했을 때 암호화 기술의 주요 돌파구였습니다. TLS는 Diffie-Hellman과 같은 키 교환 프로토콜을 사용하지만 중간자 공격으로부터 보호하기 위해보다 정교합니다. 이 프로토콜을 사용하면 정보를 교환 한 적이없는 두 사람이 모든 메시지를 볼 수있는 비밀 키를 계산할 수 있습니다.

공유 비밀 키가 있으면이를 사용하여 트래픽을 암호화 할 수 있습니다. 악의적 인 사용자는 키를 알지 못하므로 사용자가 보낸 것처럼 보이는 트래픽을 암호화 할 수 없습니다.

이제 그 각주.

  • SSL/TLS 프로토콜이 올바른 것으로 가정합니다. 가장 관련성이 높은 암호화 프로토콜을 통해 버그가 발견되고 수정됩니다. SSL/TLS에는 최근 버그가 있었지만 (안전하지 않은 이유로 몇 가지 답변에서 언급되었지만) 일시적으로 해결되었으며 현재 fixed (RFC 5746) 다양한 배포 단계. 시나리오에서 악의적 인 사용자는 자신의 이름으로 패킷을 보낼 수 있지만 트래픽을 읽을 수는 없었습니다. 공격자는 프로토콜의 게시되지 않은 오류로 인해 TLS/SSL을 끊는 방법을 항상 알고있을 수 있습니다.
  • 명백한 점이지만 반복 할 가치가 있습니다. 악의적 인 사용자가 자신의 요청을보고 자신의 인증서를 사용하여 자신의 응답을 보낼 수 있습니다. 인증서도 확인하십시오.
  • 아마도 또 다른 명백한 점 : 현재 페이지가 HTTPS 인 경우 SSL/TLS가 향후 페이지에 사용될 것이라고 확신 할 수 있습니다. 예를 들어, 로그인을 원하는 HTTP 페이지에 있고 과거 경험에서 로그인 버튼을 클릭하면 HTTPS 연결로 리디렉션된다는 것을 알고있는 경우이 기능은 악의적 인 활성 사용자에 의해 제거 될 수 있습니다 네트워크에서. 따라서 로그인 페이지가 수정되었는지 감지하는 방법을 모르는 경우 이미 HTTPS 인 페이지에만 로그인하십시오.
13
PulpSpy

안전하지 않은 네트워크를 통해 일부 사이트를 안전하게 탐색하려는 경우 보안을 위해 수행 할 수있는 최선의 단계는 다음과 같습니다.

  • 사이트가 HTTP가 아닌 HTTPS를 사용하는지 확인하십시오.

  • 사이트에 유효한 인증서가 있는지 확인하십시오. 경고를 클릭하지 마십시오. 유효하지 않은 인증서를 수락하지 마십시오.

  • HTTPS Everywhere 또는 Force-TLS 를 사용하여 해당 사이트와 관련된 모든 항목에 HTTPS (즉, SSL 암호화) 연결을 사용하고 있는지 확인하십시오.

2
D.W.

HTTPS는 패킷 스니핑으로부터의 해독에 매우 강합니다. 그러나 서버 인증 측면은 CA 인증서를 배포하는 다소 약한 방법에 의존하며 CA는 ID 확인 측면에서 별다른 역할을하지 않습니다. 몇 년 전에 Microsoft 인증서는 임 포스터에게 발급 였습니다. 일반적인 공개 웹 사이트의 경우 Bruce Schneier의 주제에 관한 기사 -를 참조하십시오. 실제로는 더 나은 것이 없습니다.

2
RedGrittyBrick

실제로 SSL과 TLS에는 모두 문제가 있지만 Man In the Middle 유형의 공격이 있습니다. TLS MITM 재협상 문제의 예는 here 를 참조하십시오.

물론이 공격은 공격자가 통신 경로의 중간에 있어야 위협을 약간 제한 할 수 있습니다.

2
Rory Alsop

전체적으로 실용적입니다. 암호화는 루트 ssl 사용자 (Verisign, Thawte 등)부터 시작하므로 안전하지 않은 회선에 적합합니다. AFAIK TLS는 중간 공격에서 사람에게 문제가 없으며 그 문제가있는 유일한 약한/오래된 악수입니다.

1
tobylane

대부분은 사용자 측면과 핫스팟에서 해당 PC를 사용하는 방법을 잊고 있습니다. 대부분의 사람들은 다른 사이트에서 비슷한 암호를 사용하고 블로그 등을 할 수 있습니다. 연결하려는 HTTPS/SSL Gmail만큼 안전하지 않을 수 있습니다. 문제 보안 상 대부분의 사람들이 다른 사이트로 이동하여 귀하의 계정 중 일부에 액세스하기에 충분한 정보가있는 패킷 스니핑 프로그램을 노출시킵니다. 암호화되지 않은 무선 연결을 사용하는 경우 언급 한 바와 같이 최상의 보안 계층을 추가 할 수 있도록 VPN을 사용할 수 있기를 바랍니다.

1
IrqJD

보안 연결 (ssl)에 관한 한 연결은 매우 안전합니다. 인식과 함께 사용되는 경우 제공 :

  • HTTPS에서 HTTP 로의 리디렉션이 없어야합니다
  • 일부 사이트는 HTTPS 페이지에서 HTTP cmd를 사용하므로 민감한 정보가 전송되어서는 안됩니다.
  • 취약한 구성의 https 서버 및 오래된 브라우저는 여전히 보안 소켓을 통해 이용할 수 있습니다
0
8zero2.ops