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

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를 같은 용도로 사용하지 않습니다. 그 이유는 역사적으로 이러한 구현과 함께 제공된 도구 때문입니다. 보안 관련 차이로 인한 것이 아닙니다 . SSL 또는 SSH를 구현하는 사람은 두 프로토콜 모두에서 어떤 종류의 공격이 시도되었는지 확인하는 것이 좋습니다.

댓글 h3>

• 잘했습니다. 실제로 SSH는 SSL보다 설정하기가 쉽기 때문에 많은 사람들이 SSH 내부에서 http (https가 아님)를 터널링합니다. 예를 들어 웹으로 원격 시스템 관리를 수행합니다. ebox 또는 webmin과 같은 GUI 도구입니다.
• 참고로, ‘ SSH 직원이 “는 사실이 아닙니다. div> 반드시 ” SSL을 사용해야합니다. SSH는 공격 표면이 작고 매우 안전하도록 특별히 설계되었습니다. SSHv2에는 문제가 없으며 SSL / TLS의 함정이 있으므로 더 작은 것을 사용하여 덜 복잡하고 잘 견디면서 상황에 훨씬 더 적합한 것을 나왔습니다. 당신이 얼마나 편집증인지에 따라 다릅니다. SSL은 ‘ 애플리케이션에 따라 사용할 수 없지만 SSH ‘의 디자인으로 상황에서 허용됩니다. SSL이 단순히 신뢰되지 않는 / security 커뮤니티.
• @NicholasWilson ” SSH ‘의 디자인은 SSL이 단순한 상황 / 보안 커뮤니티에서 수용 가능하도록합니다. 신뢰할 수 없습니다 ” 예 :
• SSL과 SSH는 병렬로 개발되었습니다 (둘 다 1995 년에 출시됨). SSL을 사용할 수 있었는지 명확하지 않습니다. 최신 SSL 2.0을 사용 했어야했는지 는 매우 모호합니다. 🙂
• 음, SSH 2.0은 프로토콜을 완전히 다시 작성했으며 1999 년경에 등장했습니다. SSL 3.0 또는 TLS 1.0을 재사용 할 수 있습니다. 하지만 물론 TLS는 X.509와 연결되어있는 것처럼 보이므로 개발자를 겁나게합니다.

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

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

SSH에는 SSL이없는 사용자 인증 레이어가 있습니다 (왜냐하면 SSL이 필요하지 않기 때문입니다. SSL은 SSH도 수행 할 수있는 두 개의 연결 인터페이스를 인증하기 만하면됩니다). UTF-8 아트에서 :

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

잠재적 인 공격이 더 많이 발생하는 문제와 관련하여 SSH의 공격 표면이 더 넓은 것이 분명해 보입니다.하지만 이는 SSH가 전체를 가지고 있기 때문입니다. 적용하다 기본 제공 : SSL의 공격 표면 + 제공해야하는 모든 애플리케이션 은 충분한 정보가 없기 때문에 비교할 수 없습니다.

댓글

• -1 합리적인 비교입니다. OP가 SSL을 유닉스 프로그램 ssh (1) 과 비교한다고 잘못 가정했습니다. SSH는 실제로 전송 계층 보안을 제공하는 또 다른 프로토콜로, 원격 셸 및 원격 실행에 대한 특수 조항이 있습니다.
• +1 @jpillora 두 가지를 비교하는 것이 합리적이라는 데 동의하지만 SSH라는 용어는 다음과 같습니다. 일반적으로 SSL / TLS와 직접 비교할 수있는 전송 계층 보안을 처리하는 SSH 프로토콜의 하위 집합을 참조하는 데 사용되지 않습니다. 이 답변에 설명 된 방식으로 SSL / TLS와 다른 애플리케이션 계층 프로토콜을 참조하는 데 거의 독점적으로 사용됩니다.
• @freb 방식 ‘ 일반적으로 언급 된 re는 문제의 진실을 변경하지 않습니다. SSH는 ssh 유틸리티의 전송 계층으로 사용되는 프로토콜입니다. 승인되고 가장 많이 득표 된 답변은이 사실을 반영합니다.
• @jpillora 저는 단지 SSH 전송 레이어 프로토콜이 대부분의 사람들이 의미하는 바라고 생각하지 않는다는 것을 의미했습니다. ‘ 질문의 문구가 주어졌습니다. 그러나 정답으로 받아 들여진 답을 감안할 때 OP가 요구 한 것임에 틀림 없습니다.
• @freb 맞습니다. 대부분의 사람들은 구절이 주어 졌다고 생각하므로이 공통점을 수정하는 것이 더욱 중요합니다. 오해.

엄격한 암호화 관점에서 둘 다 인증 된 암호화를 제공하지만 다른 방법들.

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

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

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

코멘트

• SSH ‘의 바이너리 패킷 프로토콜은 암호화 및 MAC으로 모든 일반 텍스트 메시지 (m)에 대해 암호문 E (m) ++ MAC (m)을 전송합니다 (암호화 된 연결 MAC을 사용하는 메시지)와 E (m ++ MAC (m))를 수행하는 SSL. 그러나 SSH는 바이너리 패킷 프로토콜 (키 관리, 원격 셸 클라이언트 / 서버, 파일 전송 등) 그 이상이며, SSL (현재 TLS라고 함)은 다음을 추가하는 다른 프로토콜에 사용되는 전송 계층 프로토콜입니다. 필요한 기능 (예 : HTTPS, FTPS, IMAPS 등). crypto.stackexchange에서 EtM, E & M, MtE 비교도 참조하세요.com / questions / 202
• 완전히 동의했습니다. 제가 쓴 것보다 훨씬 많은 것이 있습니다. 엄격한 암호화 관점에서 ‘ incipit ” “.
• BEAST는 MtE와 관련이 없으며 CBC (SSL3 및 TLS1.0에서)가있는 알려진 IV 때문입니다. SSH2도 수정하고 수정하지 않았습니다. 비록 그것과 TLS가 AEAD = GCM (TLS도 CCM) (그리고 ChaCha / Poly 둘 다)을 더 나은 대안으로 얻기 전에 대안으로 CTR을 얻었지만. MtE + CBC 패딩 기반 공격은 POODLE 및 Lucky13입니다.
• 출력 크기 = 입력 크기이고 암호에 약한 데이터 입력이없는 모든 암호에 대해 MAC-then-Encrypt를 안전하게 만드는 솔루션이 있습니다. 핵심.
• 이 답변은 현재 TLS가 수행하는 작업이 아니기 때문에 구식입니다.

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

ssh는 열쇠 (비공개)와 자물쇠 (공개)

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

ssl은 두 대의 컴퓨터 서버. 예 : Yours 및 연결 대상.

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

댓글

• ” 문과 벽돌 ” 댓글을 전혀 설명하지 않습니다. SSL에는 공개 및 개인 키도 있습니다. 클라이언트 인증에도 SSL을 사용할 수 있습니다. SSH는 또한 클라이언트와 서버 간의 보안 링크를 제공합니다.

SSL은 터널링되는 콘텐츠에서 추상화됩니다. SSH는 쉘 (SH)의 보안 버전이며 그 아래에 추상 계층을 포함하도록 설계되지 않았으며 쉘 트래픽을 전달하도록 특별히 설계되었습니다. 따라서 암호화 작업이 두 가지 모두에서 사용되며 이러한 암호화 작업은 동일 할 수도 있지만 목적과 전체적인 디자인은 상당히 다릅니다.

위에서 언급 한 것처럼 특정 차이점이 있음을 명심하십시오. ), 그러나 이러한 차이점의 전부는 아니지만 대부분은 서로 다른 프로토콜의 목적에 뿌리를두고 있습니다.

댓글

• -1 귀하는 잘못 가정했습니다. 해당 OP는 SSL을 유닉스 프로그램 ssh (1) 와 비교하고 있습니다. SSH는 실제로 전송 계층 보안을 제공하는 또 다른 프로토콜로, 원격 셸 및 원격 실행을위한 특수 조항이 있습니다.

SSH 대 SSL (TLS)을 정말로 찾고 있다면 답은 SSH입니다.

SSH가 SSL을 능가하는 한 가지 이유는 인증을 수행하는 방식입니다. 이러한 이유로 FTP를 사용할 때 FTPS (FTP over SSL) 대신 SSH 프로토콜 (SFTP)을 사용합니다.

SSH는 다음 용도로 회사 네트워크에서 사용됩니다. / p>

• 사용자 및 자동화 된 프로세스에 대한 보안 액세스 제공
• 대화 형 및 자동화 된 파일 전송
• 원격 명령 실행

출처 : https://www.ssh.com/ssh/protocol/#sec-Typical-uses-of-the-SSH-protocol

댓글

• ” SSH가 SSL을 능가하는 한 가지 이유는 인증을 수행하는 방식입니다. “이 주장에 대한 출처 나 설명이 있습니까?
• SSH에서는 서버를 연결하는 두 가지 옵션이 있습니다. 키 기반 인증 옵션을 사용하면 먼저 SSH 개인 키와 공개 키를 미리 생성해야합니다. 추가 작업이 많지 않습니다. 이것은 또한 최상의 보안 관행을 고려합니다. SSL에는 너무 많은 버전이 있으며 최신 버전은 TLS1.2입니다.즉, ‘ 아직 안전하지는 않지만 개선 될 예정입니다.
• TLS에도 클라이언트 측 인증서가 있습니다. SSH가 “이기는 이유를 설명하지 않습니다 “.
• 어딘가에서 복사 / 붙여 넣기하려는 경우, 출처를 인용하세요.
• ” SSL에는 너무 많은 버전이 있습니다. ” 따라서 6 개 버전은 ” 너무 많습니까 “? OpenSSH는 버전 7.7에 있습니다. ” 즉, ‘ 아직 안전하지는 않지만 개선되는 과정에 있습니다. ” 여기에서는 논리가 의미가 없습니다.

문제는 두 가지입니다. ” 암호화의 강점과 약점이 아니라 전달의 용이성과 편리 성입니다. 따라서 비즈니스 관점에서 SSL / TLS는 브라우저와 공용 또는 개인 인증서 만 필요하기 때문에 더 편리하고 쉽습니다.

그리고 SSH를 사용하려면 애플리케이션이나 씬 클라이언트가 설치되어 있어야합니다. 이는 사용자 인터넷 클라이언트 관점과 지원 측면에서 볼 때 더 많은 문제입니다.