it-swarm-korea.com

SSL과 SSH의 차이점은 무엇입니까? 어느 것이 더 안전합니까?

SSH와 SSL의 차이점은 무엇입니까? 비교할 수 있음 인 경우 어느 것이 더 안전한가요?
어떤 잠재적 취약점이 더 있습니까?

212
Am1rr3zA

SSL과 SSH는 모두 암호화 요소를 제공하여 무결성 검사를 통해 기밀 데이터 전송을위한 터널을 구축합니다. 이 경우 유사한 기술을 사용하고 동일한 종류의 공격을 겪을 수 있으므로 둘 다 올바르게 구현되었다고 가정하면 유사한 보안 (예 : 좋은 보안)을 제공해야합니다. 둘 다 존재한다는 것은 일종의 NIH 증후군입니다. SSH 개발자는 터널 부분에 SSL을 재사용해야합니다 (SSL 프로토콜은 다양한 변형을 수용 할 수있을만큼 유연합니다. 인증서를 사용하지 않는 것을 포함하여).

그들은 터널 주위에있는 것들이 다릅니다. SSL은 전통적으로 서버 및 클라이언트 공개 키를 알리기 위해 X.509 인증서를 사용합니다. SSH는 자체 형식이 있습니다. 또한 SSH에는 터널 내부 내부 (-여러 전송 다중화, 터널 내에서 암호 기반 인증 수행, 터미널 관리)를위한 프로토콜 세트가 제공됩니다. ..) SSL에 해당 사항이 없거나보다 정확하게 SSL에 사용되는 경우 SSL의 일부로 간주되지 않습니다 (예 : SSL 터널에서 비밀번호 기반 HTTP 인증을 수행하는 경우) "HTTPS"의 일부이지만 실제로 SSH와 비슷한 방식으로 작동합니다.

개념적으로 SSH를 사용하여 터널 부분을 SSL의 부분으로 교체 할 수 있습니다. 또한 HTTPS를 사용하여 SSL을 SSH-with-data-transport 및 인증서에서 서버 공개 키를 추출하는 후크로 바꿀 수 있습니다. 과학적으로 불가능한 것은 없으며, 올바르게 수행하면 보안은 동일하게 유지됩니다. 그러나 광범위한 규칙이나 기존 도구가 없습니다.

따라서 우리는 같은 일에 SSL과 SSH를 사용하지 않지만, 역사적으로 이러한 프로토콜의 구현과 함께 툴이 제공 한 도구 덕분에 not 보안 관련 차이점. 그리고 SSL 또는 SSH를 구현하는 사람은 두 프로토콜 모두에서 어떤 종류의 공격이 시도되었는지 살펴 보는 것이 좋습니다.

199
Thomas Pornin

이것은 합리적인 비교가 아닙니다. SSL은 네트워크를 통해 전송되는 데이터를 보호하는 일반적인 방법이며 SSH는 원격 컴퓨터에 로그인하여 데이터를 공유하는 네트워크 응용 프로그램입니다.

SSH의 전송 계층 보호는 SSL과 기능이 유사하므로 "보다 안전한"보안은 특정 위협 모델이 요구하는 사항과 각 구현이 처리하려는 문제를 해결하는지 여부에 따라 다릅니다.

그런 다음 SSH에는 SSL이없는 사용자 인증 계층이 있습니다 (필요하지 않기 때문에-SSL은 SSH가 수행 할 수있는 두 개의 연결 인터페이스 만 인증하면 됨). UTF-8 아트에서 :

      SSL              SSH
+-------------+ +-----------------+
| Nothing     | | RFC4254         | Connection multiplexing
+-------------+ +-----------------+
| Nothing     | | RFC4252         | User authentication
+-------------+ +-----------------+
| RFC5246     | | RFC4253         | Encrypted data transport
+-------------+ +-----------------+

잠재적 인 공격이 더 많이 발생하는 문제와 관련하여 SSH의 공격 영역이 더 큰 것이 분명합니다. 그러나 SSH에 전체 응용 프로그램이 내장되어 있기 때문입니다. 정보가 충분하지 않기 때문에 SSL + 제공해야하는 응용 프로그램의 공격 영역을 비교할 수 없습니다.

87
user185

엄격한 암호화 관점에서 두 가지 방법으로 인증 된 암호화를 제공합니다.

SSH는 소위 Encrypt-and-MAC를 사용합니다. 즉, 암호화 된 메시지는 무결성을 추가하기 위해 일반 메시지의 메시지 인증 코드 (MAC)에 병치됩니다. 실제 상황에서 충분하더라도 항상 완전히 안전한 것으로 입증되지는 않았습니다.

SSL은 MAC-then-Encrypt를 사용합니다. MAC은 일반 텍스트와 병치 된 후 둘 다 암호화됩니다. 일부 블록 암호 모드의 경우 MAC의 일부를 추측하고 암호에서 무언가를 밝힐 수 있기 때문에 이것은 최고도 아닙니다. 이로 인해 TLS 1.0 (BEAST 공격)의 취약점이 발생했습니다.

따라서 둘 다 잠재적 인 이론적 약점을 가지고 있습니다. 가장 강력한 방법은 Encrypt-then-MAC (암호화 된 메시지의 MAC 추가)이며, 예를 들어 IPsec ESP에서 구현됩니다.

12
Halberdier

간과 된이 비교에는 한 가지 측면이 있다고 생각합니다. user185가 가까이 왔지만 도착하지 못했습니다. 나는 이것들이 사과와 오렌지이며 HTTPS와 SSH에 비해 사과와 사과 사이의 더 나은 느낌을 느낍니다. HTTPS와 SSH는 OSI 모델의 서로 다른 계층을 사용하므로 전송시 서로 다른 시간에 데이터를 암호화합니다. 그렇다면 실제 데이터는 전송하는 동안이 데이터가 언제 암호화되고 암호화되지 않는지를 따라야합니다. 이것은 잠재적 인 공격 표면을 나타냅니다. HTTPS를 사용하면 대상 네트워크의 장치 (웹 서버, 경계 라우터,로드 밸런서 등)가 패킷을 수신하면 암호화되지 않고 나머지 여정을 일반 텍스트로 보냅니다. 많은 사람들은 현재 트래픽이 내부에 있기 때문에 이것이 큰 문제는 아니라고 주장하지만 페이로드에 민감한 데이터가 포함되어 있으면 모든 네트워크 장치의 로그 파일에 암호화되지 않은 상태로 저장됩니다. 최종 목적지. SSH를 사용하면 일반적으로 대상 장치가 지정되고이 장치에 도달 할 때까지 전송이 암호화됩니다. HTTPS 데이터를 다시 암호화하는 방법이 있지만 환경에서 HTTPS 솔루션을 구현할 때 가장 잊어 버리는 추가 단계입니다.

3
Sam Moore

ssh는 열쇠 (개인) 및 자물쇠 (공개)와 같습니다

ssl은 문과 벽돌과 같습니다.

ssl은 두 컴퓨터 서버 간의 보안 링크를 제공합니다. 예를 들어, 귀하와 귀하가 연결하는 사람.

ssh는 연결 컴퓨터가 자신을 확인하고 액세스 할 수있는 방법입니다.

2
datsusarachris

문제는 두 가지로, 암호화의 강점과 약점이 아닙니다. 그러나 배송이 쉽고 편리합니다. 따라서 비즈니스 관점에서 SSL/TLS는 브라우저와 공용 또는 개인 인증서 만 필요하므로 더 편리하고 쉽습니다.

그리고 SSH를 사용하려면 응용 프로그램 또는 씬 클라이언트가 설치되어 있어야합니다. 그것은 사용자 인터넷 클라이언트의 관점과 지원에서 더 많은 문제입니다.

모든 사용자, 특히 기술에 문제가있는 사용자는 밝지 않습니다.

내 2 센트.

0
Stanley Hutchinson

SSL은 터널링되는 콘텐츠에서 추상화 된 프로토콜 계층입니다. SSH는 SSH (Secure Shell) 버전으로, 그 아래에 추상 계층을 포함하도록 설계되지 않았으며, 특히 Shell 트래픽을 전달하도록 설계되었습니다. 따라서 암호화 작업이 두 가지 모두에 사용되지만 암호화 작업은 동일 할 수 있지만 목적과 전반적인 디자인은 완전히 다릅니다.

위에서 언급 한 바와 같이 특정 차이점이 있지만, 모든 차이점이 다른 프로토콜의 목적에 뿌리를두고있는 것은 아닙니다.

0
Gobbly