it-swarm-korea.com

설정된 HTTPS 연결이 회선이 실제로 안전하다는 것을 의미합니까?

웹 애플리케이션을 제공하는 누군가의 관점에서 볼 때 누군가가 TLS (https)와 당사 서비스에 연결하고 올바른 인증 데이터를 제출할 때이 라인을 통해 모든 민감한 데이터를 전송하는 것이 안전합니까, 아니면 도청이 계속 될 수 있습니까?

이 질문은 금주의 IT 보안 질문입니다.
자세한 내용은 2011 년 7 월 29 일 블로그 항목 또는 자신의 제출 금주의 질문.

112
Peter Smit

SSL이 수행하는 것과 수행하지 않는 것을 이해하는 것이 중요합니다. 특히 이것이 오해의 원인이되기 때문입니다.

  • 채널을 암호화합니다
  • 무결성 검사를 적용합니다
  • 인증을 제공합니다

따라서 빠른 답변은 "그렇습니다. 민감한 데이터를 전송하기에 충분히 안전합니다". 그러나 일이 그렇게 간단하지 않습니다.

  • SSL의 최신 버전-버전 3 이상 : TLS, 심지어 TLS 1.2도 이전 버전보다 확실히 좋습니다. 예 : SSL 2는 MITM (Man in the middle)에 비교적 쉬웠습니다. 따라서 먼저 프로토콜 버전에 따라 다릅니다.
  • 채널 암호화 및 무결성 검사는 프로토콜에서 구성 할 수 있습니다. 즉, 사용할 알고리즘 (암호 모음)을 선택할 수 있습니다. 분명히, 당신이 RSA1024/SHA512를 사용한다면 훨씬 더 나을 것입니다 ... 그러나 SSL은 심지어 NULL 암호화 모드를 지원합니다. 즉, 전혀 암호화되지 않고 SSL 프로토콜을 통해 터널로 요청을 래핑합니다. 즉, 보호가 없습니다. (이는 클라이언트와 서버 모두에서 구성 할 수 있으며, 선택된 암호 스위트는 구성된 순서에 따라 첫 번째 일치 세트입니다).
  • SSL 인증에는 서버 인증과 상호 인증 (클라이언트 인증서)의 두 가지 모드가 있습니다. 두 경우 모두 암호화 인증서로 보장되는 보안은 충분히 강력하지만 실제 인증의 유효성은 유효성 검사만큼이나 좋습니다. 인증서 검사를 귀찮게합니까? 당신은 그 유효성을 보장합니까? 트러스트 체인? 누가 발행 했습니까? 기타.
  • 이 마지막 포인트 재 인증은 웹 applications에서 훨씬 더 쉽습니다. 여기서 클라이언트는 서버 인증서를 쉽게 볼 수 있고 잠금 아이콘을 쉽게 볼 수 있습니다. 웹을 사용하면 서비스, 일반적으로 플랫폼 선택에 따라 유효성을 확인하는 데 더 명확해야합니다. 앱 개발자가 전화와 서버간에 TLS 만 사용하는 것을 기억 했더라도 앱이 인증서를 명시 적으로 확인하지 않으면 TLS가 손상되었다는 점에도 불구하고이 같은 점이 너무 많은 모바일 앱을 넘어 섰습니다.
  • SSL 암호화에 대한 이론적 인 공격이 대부분 있지만 PoV는 여전히 거의 모든 목적을 위해 충분히 강력하며 오랫동안 지속될 것입니다.
  • 다른 쪽 끝에있는 데이터로 실제로 수행되는 작업 예 : 매우 민감하거나 신용 카드 데이터 인 경우 브라우저 캐시 또는 기록 등에서 원하지 않습니다.
  • "보안"속성으로 명시 적으로 표시되지 않는 한 쿠키 (및 인증)는 보안, SSL 채널 및 비보안 HTTP 채널간에 공유 될 수 있습니다.

그래서 짧은 대답? 예, SSL can 충분히 안전하지만 (대부분의 경우와 마찬가지로) 사용 방법에 따라 다릅니다. :)

94
AviD

여기에 몇 가지 문제가 있는데, 주요 문제는 인증입니다. 양쪽 끝은 중간자 공격을 막기 위해 올바른 사람이나 기관과 대화하고 있는지 확인해야합니다. 결국에는 사용자 브라우저가 신뢰하는 SSL 인증서를 사용해야합니다. 이렇게하면 사용자의 브라우저가 실제로 올바른 사이트와 대화하고 있는지 확인할 수 있습니다. 연결이 설정되면 항상 해당 사용자와 대화하고 연결이 암호화됩니다 (예 : 도청 방지).

다른 방향으로 인증 (즉, 실제 사용자와 대화하고 있는지 확인)은 일반적으로 응용 프로그램 수준에서 SSL 프로토콜 외부에서 사용자 이름/암호, openID 또는 다른 형태의 자격 증명을 통해 처리됩니다.

마지막으로 SSL 연결 핸드 셰이크 클라이언트와 서버는 Cipher suite 에 동의하고 클라이언트는 "널 암호화"만 할 수 있습니다. 즉, 데이터를 암호화하지 않습니다. . 서버가 해당 옵션에 동의하면 연결은 SSL을 사용하지만 데이터는 여전히 암호화되지 않습니다. 서버 구현은 일반적으로 널 암호를 옵션으로 제공하지 않기 때문에 이것은 실제로 문제가되지 않습니다.

23
Tronic

AviD에 나와있는 내용 외에도 SSL은 해당 서버로 연결 한 DNS 인프라와 통신 경로의 회사 프록시만큼 안전합니다.

DNS 인프라가 해킹되면 (캐시 ​​포이즌 등) 공격자는 사용자에게 많은 공격을받을 수 있습니다.

또한 클라이언트가 Fiddler 와 같은 소프트웨어 또는 회사 프록시를 사용하는 경우 해당 소프트웨어는 SSL 대화를 방해 할 수 있습니다.

이를 완화하려면 SSL 인증서의 "발급자"를보십시오. SSL 연결이 프록시를 통과하는 경우 발급자는 프록시의 것입니다. 직접 연결을 진행하는 경우 공개적으로 신뢰할 수있는 관련 CA가 표시됩니다.

[추가 정보]

회사 HTTPS 프록시는 웹 브라우저와 프록시 (웹 서버 로그에 IP 주소가 표시되는) 간의 연결을 관리하는 것입니다. 이 경우 웹 컨텐츠 (HTTPS 비밀번호도)가 해독 된 후 나중에 회사 프록시에서 다시 암호화되어 서버에 제공됩니다.

프록시를 관리하는 사람과 로그 사용 방법에 따라 이는 사용자의 관점에서 받아 들여 지거나 나쁜 것일 수 있습니다.

SSL 차단이 수행되는 방법에 대한 자세한 내용은 다음 link 를 참조하십시오.

SSL 프록시가 SSL 연결을 가로 채면 에뮬레이트 된 서버 인증서를 클라이언트 브라우저에 제공합니다. 브라우저가 ProxySG에서 사용하는 발급자를 신뢰하지 않기 때문에 클라이언트 브라우저는 최종 사용자에게 보안 팝업을 발행합니다. SSL 프록시가 사용하는 발급자 인증서를 클라이언트 브라우저의 인증서 저장소에서 신뢰할 수있는 루트로 가져 오는 경우이 팝업이 발생하지 않습니다.

ProxySG는 구성된 모든 인증서를 관리 콘솔을 통해 다운로드 할 수 있도록합니다. 최종 사용자에게 Internet Explorer 또는 Firefox를 통해 발급자 인증서를 다운로드하여 선택한 브라우저에 신뢰할 수있는 CA로 설치하도록 요청할 수 있습니다. 이것은 에뮬레이트 된 인증서에 대한 인증서 팝업을 제거합니다 ...

일부 회사는 GPO를 통해 각 워크 스테이션에 프록시의 루트 인증서를 배포하여 위에서 언급 한 인증서 팝업 문제를 해결합니다. 이것은 Microsoft 인증서 저장소를 사용하는 소프트웨어에만 영향을 미칩니다. Firefox 및 Chrome과 같은 소프트웨어는 다르게 업데이트해야합니다.

20
goodguys_activate

SSL은 CA (Certificate-Authorities)에 의존하고 기본적으로 모든 조직이 CA가 될 수 있으므로 가짜이지만 CA 서명 된 인증서로 중간자 공격이 항상 가능합니다. 따라서 SSL은 여전히 ​​암호화가 아닌 것보다 크게 향상되었지만 CA 시스템이 손상되어 보안이 과대 평가되었습니다. 이와 관련하여 자체 서명 인증서는 CA 서명 인증서와 마찬가지로 안전하지만 브라우저는 해당 인증서를 의심스러운 것으로 표시합니다.

11
Jörn Zaefferer

SSL은 매우 안전하지만 암호화되지 않은 행을 통해 모든 페이지를 실행하면 누군가가 누군가의 세션 쿠키를 훔칠 수 있습니다. 가능하다면 사이트를 모두 SSL로 만들 수 있습니다. 또는 쿠키가 암호화 된 연결 만 보내도록하고 해당 사용자와 관련이없는 보안되지 않은 공개 페이지가있을 수 있습니다.

10
James T

중간자 (man-in-the-middle) 공격이 여전히 발생할 가능성이 있으며,이 경우 사용자는 귀하의 사이트라고 주장하는 제 3 자에 연결 한 다음 요청을 전달합니다. 물론, 정통한 사용자는 SSL 연결이 없거나 잘못된 인증서를 인식해야하지만 대부분의 사용자는이 스위치가 켜져 있지 않으며 자물쇠 즐겨 찾기 아이콘에 의해 속이는 것입니다.

이것은 실제로 SSL 자체의 문제가 아니라 알아야 할 사항입니다. 아무도 사이트와 연결 소스 사이의 SSL 연결을 도청 할 수 없다고 가정 할 수 있습니다. 그러나 연결 소스가 실제로 사용자인지 확인할 수는 없습니다.

9
Magnus

SSL은 전송을 암호화하므로 인증서를 신뢰할 수 있으므로 데이터를 도청 할 수 없습니다.

문제는 웹 응용 프로그램에서 SSL을 사용하는 위치와 양에 있습니다. 쿠키를 다시 보낼 때 쿠키가 쉽게 가로 챌 수 있다는 것을 알아야합니다 (예 : 사용자가 보호되지 않은 무선 연결에있는 경우).

최근 FireSheep 드라마가이 모든 것입니다.

9
gbr

아니요. 트래픽 분석 여전히 많은 사람에게 말할 수 있습니다.

트래픽 분석은 통신 패턴에서 정보를 추론하기 위해 메시지를 가로 채고 검사하는 프로세스입니다. 메시지가 암호화되어 해독 할 수없는 경우에도 수행 할 수 있습니다. 일반적으로, 관찰되거나 저장 및 저장되는 메시지 수가 많을수록 트래픽에서 더 많이 추론 될 수 있습니다.


TLS는 일반적으로 기밀성을 유지하기 위해 배포됩니다. 공격자는 통신 내용에 대해 높은 수준의 신뢰에 도달해서는 안됩니다.

가정의 방,

  1. 공격자가 프로토콜을 알고
  2. 공격자는 누가 누구와 통신하는지 알고 있습니다
  3. 침입자는 메시지를 해독 할 수 없습니다.
  4. 당신은 많은 말도 안되는 트래픽 (chaff)에서 실제 트래픽을 가리지 않습니다.

공격자는 아마도 프로토콜에 관계없이 깨어있을 때와 잠들었을 때를 알려줄 수 있으며 사용중인 프로토콜의 특성에 따라 더 많이 알 수 있습니다.


프로토콜이 매우 간단한 경우 :

  1. 핵무기를 발사하려고 할 때 "핵무기 발사 ..."메시지를 보냅니다.
  2. 핵무기를 발사하고 싶지 않을 때는 메시지를 보내지 않습니다.

데이터를 해독 할 수없는 도청자는 핵무기를 발사하려는 메시지의 존재 여부 만 알 수 있습니다.


프로토콜이 더 복잡한 경우 :

  1. 당신은 책을 요구합니다.
  2. 내용을 보내드립니다.

공격자는 "War and Peace"vs "Atlas Shrugged" 페이지 소설 "변형".

7
Mike Samuel

SSL은 인증과 암호화의 두 가지 기본 작업을 수행합니다.

인증은 인증 기관 (CA)을 통해 수행됩니다. 브라우저에는 CA의 서명 키에 대한 SSL 인증서 목록이 제공됩니다. CA는 엔터티의 공개 키를 설명하는 인증서에 서명합니다. 예를 들어, Google.com을 보유하고 있다면 Verisign에게이를 증명하고 일정 기간 동안 인증서에 서명합니다. CA가 서명하면 안되는 인증서에 서명하면 문제가 발생합니다. 누군가가 다른 도메인을 소유 한 척하거나 너무 넓은 와일드 카드 인증서를 얻거나 CA가 사악한 것 (정부, 아마도?)을 발행하기 위해 CA (일반적으로 XKCDs )를 획득 할 때 이런 일이 발생할 수 있습니다. 우리는 위의 모든 상황이 발생하는 것을 보았지만 매우 드 rare니다.

사이트 인증서가 올바르게 서명되고 트러스트 체인에 가짜 인증서가 없으면 사이트에 연결할 때 (토론 목적으로) 인증서가 일치한다고 확신 할 수 있습니다. 정상적인 상황에서는 해당 연결이 암호화됩니다. 그것은 누군가가 당신의 데이터를 읽지 못하게합니다.

SSL 인증서는 매우 복잡하며 SSL 구현에 여러 가지 공격이 존재합니다. SSL로 효과적으로 할 수있는 것은 GMail에서 이메일을 확인할 때 로컬 스타 벅스에서 트래픽을 보지 못하게하는 것입니다. 그것이 할 수없는 것은 SSL없이 내가 당신에게 모든 것을 릴레이하고 클라이언트가 암호화 된 세션을 시작하지 않은 사실에 대해 귀찮게 설정하지 않는 MITM 공격을 사용하지 못하게하는 것입니다.

6
Jeff Ferland

SSL 3.0과 강력한 암호화를 사용한다고 가정 할 때 다른 잠재적 인 문제에 대해 다른 사람들의 다양한 답변을 세지 않고 안전해야합니다.

오래된 SSL 프로토콜 (2.0)을 사용하거나 약한 암호화 키를 사용하면 취약성이 발생할 수 있습니다.

4
Doozer Blake

SSL은 일반적으로 다음을 제공하여 보안을 강화합니다.

  1. 서버 인증 (사용자가 '올바른'사이트와 대화하고 있음을 알고 있음)
  2. 데이터 무결성 (사용자와 서버는 전송 중에 트래픽이 수정되지 않음을 알고 있음)
  3. (선택적이지만 일반적으로) 데이터 개인 정보 보호 (사용자와 서버는 트래픽이 전송 중에 차단되지 않음을 알고 있음)
  4. (선택적으로, 드물지만) 클라이언트에 인증서가있는 경우 클라이언트 인증

본질적으로 두 가지 유형의 SSL 인증서, 즉 서버 인증서 (항상 관련)와 클라이언트 인증서 (선택적)가 있습니다.

이것은 단지 스케치 일 뿐이며 많은 if, and and buts가 있습니다. 가장 일반적인 시나리오 인 브라우저 기반 SSL에서는 암호화 또는 프로토콜을 손상시키지 않고 많은 경우에 체계가 손상 될 수 있지만 단순히 사용자에게 의존하여 잘못된 일을합니다 (즉, 브라우저 경고를 무시하고 어쨌든 연결). 피싱 공격은 URL을 제외한 모든 측면에서 실제 사이트와 유사하도록 구성된 가짜 SSL 보호 사이트로 사용자를 보내서 작동 할 수 있습니다.

SSL과 그 사촌 TLS는 최소한 안전한 통신을 허용하지만 여전히 완벽한 통신을 허용하므로 여전히 유용합니다.

4
frankodwyer

@Vladimir는 http://en.wikipedia.org/wiki/Forward_secrecy 가 바람직하지만 세부 사항이 잘못되었습니다. 서버 chose이 암호는 브라우저에 의해 offered 중 하나입니다. "메시지 인증을 위해 SHA1이있는 RC4_128로 암호화 됨"은 RC4 128 비트 암호화 및 HMAC-SHA-1 무결성 검사를 사용합니다. SSL/TLS의 암호 이름은 최근까지 SHA이지만 SHA-1과 실제로 HMAC-SHA-1을 의미합니다.) "키 교환 메커니즘으로서의 ECDHE_ECDSA"는 개별 메시지에 적용되지 않습니다. ECDHE는 세션 모드에서 Diffie-Hellman의 Elliptic Curve 변형 (여기서는 중요하지 않은 추가 단계 포함)을 사용하여 세션을 생성합니다. 암호화 및 HMAC에 사용됩니다. ECDHE 키 교환 (전용)은 디지털 서명 알고리즘의 타원 곡선 변형에 의해 서명됩니다. (DH 또는 ECDH로는 직접 암호화 할 수 없으며 키 또는 기타 작은 비밀 계약 만 수행합니다.)

2
dave_thompson_085

SSL을 사용하지 않는 경우 모든 통신을 쉽게 가로 챌 수 있습니다. 패킷 스니퍼 (예 : Wireshark)를 시작하기 만하면됩니다.
SSL은 모든 패킷이 암호화되는 것을 방지하므로 발송중인 내용을 알 수있는 방법이 없습니다. 기본적으로 비밀번호 및 개인 컨텐츠가 인터셉트되지 않도록 보호하는 데 사용됩니다. 당신은 분명히 다른 사람이 당신의 개인 이메일을 읽길 원하지 않습니다.
Google 검색의 경우 사람들이 원하는 것을 숨기려고했습니다. 일부 정부는 그것에 대해 너무 궁금하기 때문입니다.

SSL은 어떻게 보안을 강화합니까? 그 자체로는 그렇지 않습니다. 암호화 (SSL 키)와 PKI (공개 키 인프라)의 조합은 주로 인증서입니다. 문제는 방법이었습니다. 한쪽은 통신 채널을 보호하고 (위 참조) 다른 한편으로는 합법적 인 비즈니스와 대화하고 서버를 인증합니다. 따라서 채널은 안전하고 신뢰할 수 있습니다.

PKI Services 가 많기 때문에 SSL 인증서가 상당히 있습니다. 기본적으로 다른 서비스에는 다른 유형의 SSL 인증서가 필요합니다. 따라서 코드 서명, 전자 메일 암호화 및 서명, 서버 인증 등과 같은 인증서에 대한 인증서가 있습니다.

2
Paweł Dyda

누군가가 SSL (https)로 서비스에 연결하고 올바른 인증 데이터를 제출할 때이 라인을 통해 모든 중요한 데이터를 전송하는 것이 안전합니까, 아니면 도청이 계속 될 수 있습니까?

이 체인의 약한 링크는 거의 확실하게 SSL이 아니지만 일반적으로 웹 스푸핑/하이퍼 링크 스푸핑을 통해 또는 잘못된 인증서가 표시되고 브라우저 경고를 해제하고 어쨌든 연결하십시오.

그러나 귀하가 설명하는 시스템은 어쨌든 최선의 방법입니다. 할 수있는 일이 많지 않습니다 (가능한 경우 사용자에게 SSL 경고를 심각하게 지시하도록 교육하는 것 외에도).

2
frankodwyer

짧은 대답은 '아니요'입니다. 더 긴 대답 : 위의 답변 모음 플러스 : 우리가 인증을 해결하면 MITM (Man-in-the-Middle)은 전통적인 SSL 연결 somone이 트래픽을 나열하면 서버 비밀 키를 얻은 후에도 나중에 해독 할 수 있습니다 (생각 of NSA and National Security Letters). TLS 프로토콜에는 Diffie-Helman 프로토콜을 사용하여 기밀을 보장하는 옵션이 있습니다. Chrome을 사용하여 gmail.com에 액세스 할 때 다음 그림을 참조하십시오. connection security

메시지 인증 ECDHE_ECDSA에 대해서는 SHA1이있는 RC4_128 텍스트를보십시오. 이것은 읽습니다 :

  1. 서버는 SHA 다이제스트와 함께 SSL 채널 RC4_128b를 제공했습니다.
  2. 이 터널 내에서 각 메시지는 Diffie-Helman 기능을 사용하여 키가 파생되는 Ecliptic 곡선으로 암호화되고 Digital Signature Algorithm을 사용하여 Ecliptic Curves 암호로 서명됩니다.

즉, 누군가 SSL 서버의 개인 키를 가지고 있더라도 메시지는 사용 후 곧 메모리에서 삭제되는 임시 키로 암호화되었습니다. 행운을 빕니다 NSA!

2
Vladimir Jirasek

사용자에게 안전합니까, 아니면 안전합니까? 중간자 공격을 가정합니다. 공격자는 사용자의 트래픽을 캡처하고 사용자 인 것처럼 가장하고 사용자 인 것처럼 가장합니다. 사용자에게 제공된 인증서가 올바르지 않기 때문에 이러한 종류의 공격은 일반적으로 실패합니다. 예를 들어 공격자는 사용자에게 웹 사이트에 대한 자체 서명 된 인증서를 제공합니다. 그러나 사용자가 바보처럼 행동하면 자체 서명 된 인증서를 수락 할 수 있습니다. 따라서 공격자는 사용자와 사용자 사이의 모든 트래픽을 읽고 수정할 수 있으며, 내가 아는 한이를 탐지 할 방법이 없습니다.

따라서 스누핑 및 트래픽 수정으로 인해 사용자가 아프면 실제로는 자신의 잘못이며 자신의 문제입니다. 그리고 MITM은 당신을 완전히 차단하고 사용자 인 척하는 사용자와 대화하기 때문에 어쨌든 완전히 막을 수는 없습니다. 그러나 스누핑 및 트래픽 수정으로 인해 문제가 발생하면 사용자가 어리석지 않다고 믿거 나 사용자를 더 잘 인증해야합니다 (사용자는 인증서가 필요하며 MITM이 할 수없는 방식으로이를 확인할 수 있음) 모조품).

2
gnasher729

클라이언트가 CA를 신뢰하는 경우 TLS를 사용하는 최신 HTTPS 버전조차도 MitM (예 : 주니퍼 장치 목적으로 구성)에 의해 쉽게 가로 챌 수 있습니다. 이 특별한 경우에는 안전하지 않습니다.

1
user3260912

나는 여기 사람들이 그 질문을 이해하지 못한다고 생각합니다.

안전하지 않은 회선이 있고이 회선을 통해 SSH/SSL 연결에 성공한 경우 회선이 "보안"이고 암호화되지 않은 데이터를 암호화 된 연결 ( 예를 들어, 암호화 된 SSL/SSH 연결 내부가 아닌 눈에 잘 띄는 곳).

나는 아니오라고 말할 것입니다. 이 경우 암호화 된 데이터를 무시하고 암호화되지 않은 데이터를 저장하는 수동 도청기가있을 수 있습니다.

그러나 MITM (Active eavesdropper)이 없는지 확인할 수 있습니다. 즉, 인증 된 라인과 동일한 소스/대상으로 인증되지 않은 SSL/SSH 연결을 안전하게 설정할 수 있습니다. 이것은 MITM 특정 커넥터에 대한 선택적 도청을 제공하지 않았지만 도청자는 연결을 인증할지 여부를 알 수 없으므로 탐지를 회피 할 MITM에 대한 연결을 알 수 없습니다. MITM은 MITM 인 경우 모든 연결을 MITM하고 사람들이 모든 인증 대화 상자를 간단하게 클릭하기를 바랍니다.

따라서 : 123.123.123.123에서 24.24.24.24와 같이 SSL 서비스에 인증 된 연결하면 SSH 지문을 상호 인증하지 않고도 SSH 클라이언트를 123.123.123.123에서 24.24.24.24로 안전하게 연결할 수 있습니다. 다른 쪽의 NAT 라우터 또는 방화벽.

그러나 그것이 일반적으로 안전하다는 의미라도 IS 도청자가 단순히 MITM 연결을 무작위로 랜덤하게하고 탐지되지 않기를 바라는 작은 위험이 있으므로 이미 대상 IP에 대한 인증 된 연결이 있으므로 인증 된 연결을 사용하지 않는 것이 좋습니다 SSH 지문을 상호 확인하려면? SSL 보안 웹 사이트에 올바른 SSH 지문을 게시하는 것만 큼 간단합니다!

1