요약:
이 기사에서는 SSL과 SSH 프로토콜의 차이점을 살펴 보겠습니다. 우리는 그들이 어떻게 작동하는지, 암호화, 대칭 및 비대칭 암호화, 키 교환, 디지털 서명 및 인증 기관의 개념에 대한 핵심 요점에 대해 논의 할 것입니다. 또한 보안 프로토콜에서 암호화 해시 사용을 설명 할 것입니다.
키 포인트:
- SSL은 인증서 기반 인증을 사용하고 SSH는 사용자 이름/비밀번호 인증 프로세스에 의존합니다.
- 암호화는 정보를 인코딩하여 무단 액세스로부터 안전하게 유지하는 프로세스입니다.
- 대칭 키 암호화는 암호화 및 암호 해독에 동일한 키를 사용합니다.
- 공개 키 암호화라고도하는 비대칭 키 암호화는 개인 키와 공개 키로 구성된 키 쌍을 사용합니다.
- 공개 키 암호화는 당사자 간의 안전한 키 교환 및 안전한 메시징을 허용합니다.
- 대칭 암호화는 공개 키 암호화보다 빠르므로 종종 벌크 데이터 암호화에 사용됩니다.
- 디지털 서명은 공개 키 암호화를 사용하여 메시지의 진위와 무결성을 확인합니다.
- 인증서 당국은 공공 키 협회를 정당한 소유자와 보장합니다.
- 암호화 해시 알고리즘은 안전 프로토콜에서 데이터 무결성 검사에 사용됩니다.
- SSL/TLS 및 SSH는 전송 중 데이터를 보호하는 데 널리 사용됩니다.
질문:
- 인증 측면에서 SSL과 SSL이 어떻게 다른가??
- 암호화와 목표는 무엇입니까??
- 대칭 키 암호화 란 무엇입니까??
- 공개 키 암호화는 어떻게 작동합니까??
- 공개 키 암호화의 장점은 무엇입니까??
- 대칭 암호화가 벌크 데이터 암호화에 사용되는 이유는 무엇입니까??
- 디지털 서명이란 무엇입니까??
- 인증 당국의 역할은 무엇입니까??
- 암호화 해시 알고리즘은 무엇입니까??
- SSL/TLS 및 SSH는 무엇을 사용합니까??
SSL은 인증서 기반 인증을 사용하고 SSH는 사용자 이름/비밀번호 인증 프로세스에 의존합니다.
암호화는 정보를 인코딩하여 무단 액세스로부터 안전하게 유지하는 프로세스입니다. 목표는 데이터의 기밀성과 무결성을 보장하는 것입니다.
대칭 키 암호화는 데이터의 암호화 및 암호 해독에 동일한 키를 사용합니다.
비대칭 암호화라고도하는 공개 키 암호화는 개인 키와 공개 키로 구성된 키 쌍을 사용합니다. 공개 키는 암호화에 사용되며 개인 키는 암호 해독에 사용됩니다.
공개 키 암호화는 비밀 키를 공유 할 필요없이 안전한 메시징 및 당사자 간의 주요 교환을 허용합니다.
대칭 암호화는 공개 키 암호화보다 빠르므로 많은 양의 데이터를 암호화하는 데 더 효율적입니다.
디지털 서명은 공개 키 암호화를 사용하여 메시지의 진위와 무결성을 확인합니다. 그들은 메시지가 변조되지 않았으며 실제로 청구 된 발신자가 서명했다는 확신을 제공합니다.
인증서 당국은 공공 키 협회를 정당한 소유자와 보장합니다. 공개 키 정보가 포함 된 디지털 인증서를 발행하고 인증서 보유자의 신원을 확인합니다.
암호화 해시 알고리즘은 안전 프로토콜에서 데이터 무결성 검사에 사용됩니다. 주어진 입력에 대해 고유 한 해시 값을 생성하여 수신자가 데이터가 변조되었는지 확인할 수 있습니다.
SSL/TLS 및 SSH는 전송 중 데이터를 보호하는 데 널리 사용됩니다. SSL/TLS는 보안 웹 통신에 일반적으로 사용되며 SSH는 보안 원격 액세스 및 파일 전송에 사용됩니다.
SSL vs SSH- 기술적이지 않은 비교
4. SSH는 사용자 이름/비밀번호 인증 프로세스를 사용하여 안전한 연결을 설정하지만 SSL은 고려하지 않습니다.
SSL, TLS, SSH 작동 방식
이 기사에서는 안전한 네트워크 프로토콜이 어떻게 작동하는지 살펴 봅니다. 암호화, 암호화 해시 및 공개 키 암호화와 같은 주요 개념을 설명합니다. 가장 인기있는 두 가지 보안 네트워크 프로토콜 인 SSL/TLS 및 SSH가 검사 될 예정이며, 보안 파일 전송 대응 물, FTP 및 SFTP가 설명되고 비교됩니다.
암호화 가란 무엇입니까??
암호화는 암호화 된 정보를 읽을 권한이있는 당사자만이 정보를 읽을 수있는 방식으로 정보를 인코딩하는 프로세스입니다. 목표는 도청자 또는 비밀로부터 정보를 안전하게 유지하는 것입니다.
암호화되지 않은 정보는 일반 텍스트로 알려져 있으며 암호화 된 정보는 암호 텍스트라고합니다. 암호 텍스트에서 일반 텍스트를 얻으려면 암호화 키가 필요하며 승인 된 당사자 만 암호화 키 사본이 있습니다. 인코딩 프로세스는 암호화 알고리즘이라고합니다. 알고리즘은 키없이 일반 텍스트를 해독하는 데 실질적으로 불가능하게 설계되었습니다.
암호화의 두 가지 주요 유형이 있습니다 – 대칭 키 암호화 및 비대칭 또는 공개 키 암호화.
대칭 키 암호화
대칭 암호화에서 일반 텍스트를 암호화하는 데 사용되는 키와 암호 텍스트를 해독하는 데 사용되는 키는 동일합니다. 이것은 두 당사자 (발신자와 수신자)가 키를 공유해야 함을 의미합니다 (그 자체는 비밀로 유지해야합니다). 물론, 키를 안전하게 공유하는 방법을 알아내는 것은 암호화가 설계된 것의 또 다른 사례입니다 – 정보를 안전하게 공유하는 것. 그래서 두 당사자는 어떻게 비밀 키를 공유합니까?? 다행히도 이것은 비대칭 (또는 공개 키) 암호화에 의해 달성 될 수 있습니다. 인기있는 대칭 키 알고리즘에는 AES, Blowfish, RC4 및 3DES가 포함됩니다.
공개 키 암호화
공개 키 암호화는 두 개의 개별 키가 필요한 특수 알고리즘 세트를 기반으로합니다. 개인 키로 알려진 하나의 키는 비밀로 유지되며 다른 키인 공개 키는 널리 사용됩니다. 함께 그들은 키 쌍으로 알려져 있습니다. 일반적으로 누구나 암호화에 공개 키를 사용할 수 있지만 개인 키 소유자만이이를 해독 할 수 있습니다.
공개 키 암호화 시스템의 장점은 다음과 같습니다.이자형. 암호화 된) 메시지는 공개 키를 게시 한 사람에게 보낼 수 있으며 수신자 만 메시지를 해독 할 수 있습니다. 공개 키가 자신의 것으로 신뢰할 수있는 한 (중요한 경고!), 비밀 메시지를 교환하기위한 안전한 시스템을 쉽게 설정할 수 있습니다. 각 당사자는 공개 키를 게시하고 다른 사람을 사용하여 다른 사람에게 비밀 메시지를 보낼 수 있습니다’공개 키. 그들은 자신의 개인 키를 사용하여받는 메시지를 해독합니다.
그러나 그렇습니다’t 공개 키를 게시하면 암호화 된 메시지가 승인되지 않은 암호 해독에 더 취약하게 만듭니다? 아니요, 공개 키에서 키 페어의 개인 키를 도출하는 것은 실제로 불가능하며 개인 키가 없으면 암호 텍스트를 해독 할 수 없습니다. 따라서 공개 키를 게시하면 공개 키가 암호화 한 메시지를 해독하기가 더 쉽지 않습니다.
RSA와 Diffie – Hellman은 가장 초기의 공개 키 알고리즘이었습니다. 오랫동안 그들은 1976/1977 년에 발명되었다고 생각되었지만 1997 년 비밀 GCHQ 연구가 분류 될 때 몇 년 전 독립적으로 고안된 것으로 밝혀졌습니다. Elgamal과 DSS는 다른 잘 알려진 공개 키 알고리즘입니다.
아래에 설명 된 공개 키 암호화의 여러 가지 중요한 용도가 있습니다.
키 분포
대칭 암호화는 양 당사자가 요구하는 단일 비밀 키를 사용 하고이 비밀 키가 상대방과 안전하게 전달되도록하기가 어렵습니다. 이를 주요 분포 문제라고합니다.
공개 키 암호화는이 문제를 해결하는 데 이상적입니다. 발신자를 요구하는 수신 당사자’S 비밀 대칭 키, 키 페어를 생성하고 공개 키를 게시합니다. 발신자는 수신기를 사용합니다’대칭 키를 암호화하고 수신기로 보내기위한 공개 키. 이제 발신자와 수신기는 모두 동일한 비밀 대칭 키를 가지고 있으며, 아무도 명확한 텍스트로 전송 된 적이 없기 때문에 아무도 없습니다. 이것은 종종 주요 교환으로 알려져 있습니다.
명백한 질문은 모든 것에 공개 키 암호화를 사용하지 않는 이유를 묻고 비밀 키를 전혀 보내지 않아도됩니다? 암호화 및 암호 해독에서 대칭 암호화가 훨씬 빠릅니다. 따라서 공개 키 암호화를 사용하여 대칭 키를 배포 한 다음 대칭 암호화를 사용하는 것이 훨씬 더 효율적입니다.
디지털 서명
공개 키 암호화는 디지털 서명의 중요한 구성 요소입니다. 사용자와 메시지를 서명 (암호화) 할 수 있습니다’S Private Key 및 누구나 공개 키를 사용하여 사용자가 메시지에 서명했으며 메시지가 변조되지 않았는지 확인할 수 있습니다. 이 공개 키 암호화의 응용 프로그램은 다음 섹션에서 암호화 해시에 자세히 설명되어 있습니다.
인증서 당국
공개 키 암호화를 사용하는 시스템에 대한 중요한 요구 사항은 공개 키를 소유자와 안정적으로 연관시키는 방법을 제공하는 것입니다. 누군가를 사용할 수있는 가치는 제한적입니다’할 수있는 경우 메시지를 암호화하기위한 공개 키’그것은 실제로 공개 키라고 결정됩니다. 이것이 인증서 당국이 무엇을 의미하는지, 그들과 인증서는 모두 아래에 설명되어 있습니다.
암호화 해시
암호화 해시 알고리즘은 소프트웨어, 특히 SSL/TLS 및 SSH와 같은 안전한 프로토콜에서 널리 사용되는 중요한 수학적 기능입니다.
데이터 블록은 해시 알고리즘을 통해 전달되어 메시지 다이제스트 또는 단순히 Digest로 알려진 훨씬 작은 해시 값을 생성합니다. 동일한 메시지는 항상 동일한 소화를 초래합니다. 다른 메시지는 다른 다이제스트를 생성합니다.
해시 알고리즘의 중요한 특징은 특정 소화가 주어지면 제작할 메시지를 생성하는 것이 매우 어렵다는 것입니다. 그들은 “일방 통행” 알고리즘 – 메시지의 다이제스트는 계산하기 쉽지만 메시지는’다이제스트에서 추론됩니다. 충돌로 알려진 동일한 다이제스트를 생성하는 두 개의 다른 메시지가 수학적으로 가능하지만 좋은 해시 알고리즘의 경우 거의 가능하지 않습니다.
인기 해시 알고리즘에는 MD5 및 SHA-1이 포함되지만 SHA-2와 같은 더 강력한 알고리즘에 유리하게 단계적으로 폐지되고 있습니다.
해시 알고리즘은 데이터 또는 파일의 무결성 확인, 비밀번호 검증 및 메시지 인증 코드 (MAC) 및 디지털 서명과 같은 기타 암호화 기능 구축과 같은 여러 목적으로 사용됩니다.
디지털 서명
서면 서명은 알려진 저자에 의해 문서가 작성되었으며이를 정확하게 나타내는 것을 보여줍니다. 디지털 서명은 비슷합니다 – 메시지가 알려진 발신자 (인증)에 의해 작성되었으며 메시지가 Transit (Integrity)에서 변조하지 않았 음을 보장합니다.
메시지에 서명하려면 두 단계가 필요합니다. 첫째, 메시지 다이제스트가 계산되어 메시지보다 일반적으로 훨씬 작은 고유 한 해시를 생성합니다. 다음으로, 다이제스트는 메시지 서명자를 사용하여 암호화됩니다’개인 키. 이것은 메시지의 디지털 서명입니다.
메시지의 서명자를 확인하려면 두 단계가 필요합니다. 첫째, 서명자’공개 키 (광범위하게 사용 가능한)는 디지털 서명을 해독하는 데 사용되며 메시지 소화를 산출합니다. 그런 다음 메시지의 메시지 다이제스트가 계산되고 해독 된 다이제스트와 비교됩니다. 메시지가 변조되지 않은 경우 다이제스트가 동일해야합니다. 그리고 서명자 때문에’S 공개 키는 서명, 서명자를 해독하는 데 사용되었습니다’S 프라이버시 키를 암호화하는 데 사용되었을 것입니다.
메시지를 사용하는 이유’S는 전혀 소화됩니다? 왜 서명자와 메시지를 암호화하지 않겠습니까?’S 프라이버시 키 및 암호화 된 메시지를 서명으로 사용하십시오? 확실히 작동하지만 비현실적입니다. 서명이 포함될 때 메시지 크기의 두 배가됩니다. 다이제스트는 매우 작고 고정 된 크기이므로 다이제스트를 암호화하면 훨씬 작은 서명이 생성됩니다.
메시지 인증 코드 (Mac)
메시지 인증 코드 또는 Mac은 메시지가 변조되지 않았 음을 확인하고 누가이이를 만든지 인증 할 수있는 메시지에 첨부 된 작은 정보입니다.
특수 유형의 Mac은 HMAC이며 암호화 해시와 비밀 키를 사용하여 구성됩니다. 비밀 키는 메시지와 함께 패딩되고 연결되며 다이제스트 또는 해시가 계산됩니다. 이 다이제스트는 패딩 된 비밀 키와 다시 연결되어 HMAC 값을 산출합니다. 공격자가 비밀 키없이 동일한 HMAC를 생산하는 것은 불가능합니다.
발신자와 수신기는 모두 비밀 키를 공유합니다. 수신기가 메시지를 받으면 HMAC를 계산하여 메시지와 함께 제공된 HMAC와 비교합니다. HMACS가 일치하면 비밀 키를 가진 사람만이 메시지를 만들 수있었습니다. 비밀 키 자체는 결코 전송되지 않습니다.
비밀번호, 암호 해시 및 소금
암호화 해시는 암호 검증이 필요한 시스템에 매우 유용합니다. 사용자를 저장하는 것은 정당한 보안 위험입니다’암호가 암호화 되더라도 S 비밀번호. 대신, 각 암호의 다이제스트가 저장됩니다. 사용자가 암호를 공급하면 해시되고 저장된 다이제스트와 비교됩니다. 암호를 해시에서 복구 할 수 없기 때문에 바람직합니다.
이 방법의 한 가지 단점은 사용자가 동일한 암호를 가지고 있으면 해시 값이 동일하다는 것입니다. 공통 비밀번호에 대한 사전 계산 된 다이제스트 테이블을 사용하여 다이제스트가 포함 된 파일을 얻을 수있는 경우 시스템을 공격 할 수 있습니다. 이 테이블은 레인보우 테이블로 알려져 있습니다.
이러한 이유로 소금이 계산되기 전에 무작위, 비 분비 값 인 소금이 비밀번호와 연결됩니다. 모든 사용자는 다른 소금을 가지고 있기 때문에 사전 계산 된 테이블을 사용하는 것이 불가능합니다. 가능한 모든 소금 값마다 테이블이 있어야합니다. 소금이 효과적이기 위해서는 가능한 한 무작위 여야하며 적절한 크기 – 바람직하게는 32 비트 이상입니다.
인증서는 무엇입니까??
공개 키 암호화에 대해 논의하면서 공개 키를 소유자와 확실하게 연관시키는 방법이 필요하다고 설명되었습니다. 누군가를 사용합니다’그들에게 의도 된 메시지를 암호화하려는 공개 키는 그것이 실제로 공개 키라는 것을 알아야합니다.
인증 당국 이이 문제에 대한 해결책입니다. 인증 기관 (a “CA”)는 디지털 인증서를 발행하는 조직입니다. 디지털 인증서는 공개 키의 소유권을 인증하는 전자 문서입니다.
디지털 인증서에는 여러 분야가 포함되어 있습니다 – 소유권을 인증하는 공개 키, 소유자 이름 (주제), 발행자 이름 (I.이자형. CA), 시작 및 종료 날짜 및 발행자’S 디지털 서명. Digital Signature는 CA가 실제로 인증서를 발행했는지 확인합니다. 디지털 서명은 여기에 자세히 설명되어 있습니다.
시스템이 작동하려면 인증 기관이 신뢰할 수있는 제 3 자 여야합니다. Comodo, Symantec 및 Godaddy를 포함하여 소수의 CA 만 있습니다. CAS는 공개 키가 포함 된 자체 인증서를 발행하며 신뢰할 수있는 루트 인증서라고합니다.
CA로부터 인증서를 얻으려면 조직은 CA에 공개 키를 제공하고 그것이 진정한 조직임을 확인하기에 충분한 문서를 제공해야합니다. CA는 인증서를 발행하기 전에 이러한 세부 정보를 확인합니다.
웹 사이트 검증
인증서의 가장 일반적인 사용은 HTTPS 웹 사이트를 검증하는 것입니다.이자형. https : //로 시작하는 URL이있는 웹 사이트. 웹 브라우저가 Amazon과 같은 사이트에 연결하면 사용자는 사이트를 신뢰할 수 있음을 알아야합니다.이자형. URL www.아마존.com은 실제로 Amazon이라는 회사가 제어하는 사이트를 나타냅니다. 이것은 인증서에 웹 사이트 도메인 이름을 포함하여 수행됩니다’인증서에 CA에 신청할 때의 주제 필드. CA는 인증서를 발행하기 전에 도메인 이름이 조직에 의해 제어되도록합니다. 웹 브라우저에는 자체 루트 인증서 목록이 있으며 사이트에 연결할 때 사이트에 연결할 때 사이트’S 인증서는 웹 서버에서 다시 전송됩니다. CA 인증서를 사용하면 웹 서버에서 보낸 인증서가 CA 중 하나에 의해 발행되었으며 도메인 이름이 인증서의 도메인 이름과 일치하는지 확인합니다.
이 점검이 중요한 이유는 무엇입니까?? Amazon이 도메인 이름을 소유 한 한 (우리가 알고있는) 인증서를 확인하기 위해 브라우저가 필요한 이유는 무엇입니까??
불행히도 악성 소프트웨어가 다른 컴퓨터를 가장 할 수 있습니다. URL이 https : // www와 같은 웹 브라우저에 입력되면.아마존.com, 그것은 IP 주소로 변환되어야합니다.g. 192.168.1.64. 이 숫자는 브라우저가 웹 서버에 연결하는 데 사용하는 것입니다. 번역 과정을 DNS 조회라고하며, IP 주소를 얻기 위해 도메인 이름의 공개 레지스터를 확인하는 것이 포함됩니다. Amazon은 사용하기로 결정했습니다. 악성 소프트웨어는 DNS 조회를 타협하여 잘못된 IP 주소를 반환 할 수 있습니다.이 IP 주소는 Amazon과 유사하게 보이고 신용 카드 세부 사항을 얻도록 설계된 가짜 웹 사이트에 적합 할 수 있습니다.
인증서 수표가 그 가치를 증명하는 곳입니다. 가짜 웹 사이트는’t 진정한 인증서를 반환하면 웹 브라우저는 반환 된 인증서가 URL에 사용 된 도메인 이름에 등록되지 않았 음을 나타냅니다. 대부분의 브라우저에서 진짜 사이트에는 자물쇠 기호가 표시되며 마우스로 클릭하면 사이트가 표시됩니다’s는 아래의 Chrome과 마찬가지로 검증 된 신원입니다.
이것이 HTTP 대신 HTTPS로 시작하는 URL을 사용하는 것이 중요합니다. 인증서를 통해 브라우저는 연결중인 사이트가 도메인의 검증 된 소유자라는 보장을 제공 할 수 있습니다.
SSL/TLS는 어떻게 작동합니까??
역사
SSL (Secure Sockets Layer)은 TCP/IP 네트워크를 통한 통신을 보호하도록 설계된 암호화 프로토콜입니다. SSL은 1990 년 초 Netscape에 의해 개발되었습니다’s이지만 다양한 보안 결함은’s SSL까지 t.0은 1996 년에 SSL이 인기를 얻은 것으로 발표되었습니다.
이 기간 동안 SSLEAY라는 SSL의 오픈 소스 구현은 Eric Young이 제공하여 인터넷에서 광범위한 채택을 보장하는 데 도움이되었습니다. Apache 웹 서버도 인기를 얻고 있었고 Apache Fame의 Ben Laurie는 Ssleay를 사용하여 최초의 자유롭게 사용 가능한 보안 웹 서버 중 하나 인 Apache-SSL을 생산했습니다.
SSL은 TLS 1의 출판과 함께 TLS (Transport Layer Security)가되었습니다.0 표준 1999 년, TLS 1.1 및 TLS 1.2, 가장 최근 버전. 모든 버전의 TLS는 널리 사용되고 있으며 최근에 SSL 3에 대한 지원이 있습니다.푸들 취약성에 대한 응답으로 0이 중단되었습니다. 단순화를 위해, 우리’ll이 기사의 나머지 부분에 대한 ssl/tls를 tls로 언급합니다.
개요
TLS는 클라이언트간에 안전한 연결을 제공하기위한 것입니다 (E.g. 웹 브라우저) 및 서버 (E.g. 웹 서버) 사이에 전달되는 모든 데이터를 암호화하여.
일반적인 네트워크 연결은 암호화되지 않으므로 네트워크에 액세스 할 수있는 사람은 패킷, 사용자 이름, 암호, 신용 카드 세부 정보 및 네트워크 전반에 걸쳐 전송되는 기타 기밀 데이터를 스니핑 할 수 있습니다.
이 백서의 앞부분에서 공개 키 암호화 및 인증서를 포함하여 암호화가 어떻게 작동하는지 논의했습니다. TLS는 공개 키 암호화를 사용하여 암호화 된 세션에서 당사자를 확인하고 클라이언트 및 서버가 공유 대칭 암호화 키에 동의 할 수있는 방법을 제공합니다.
SSL 핸드 셰이크
그만큼 “악수” 연결에 대한 중요한 매개 변수가 설정되는 곳이므로 SSL/TLS의 가장 중요한 부분입니다. 악수의 다양한 단계는 아래에 설명되어 있습니다.
보안 네트워크 프로토콜 12
1 단계 – 클라이언트 안녕하세요
TCP/IP 연결을 설정 한 후 클라이언트는 ClientHello 메시지를 서버로 보냅니다. 이것은 클라이언트가 지원하고자하는 최대 TLS 버전, 임의 숫자, 선호 순서대로 지원되는 암호 스위트 목록 및 압축 알고리즘을 나타냅니다. 암호 스위트는 함께 사용되는 암호화 알고리즘 그룹의 식별자입니다. 예를 들어, TLS_RSA_WITH_AES_128_CBC_SHA는 서버를 의미합니다’S RSA 공개 키를 사용하고 암호화 알고리즘은 128 비트 AES입니다. 메시지 인증 코드 (MAC) 알고리즘은 HMAC/SHA-1입니다.
ClientHello는 ClearText로 전송되므로 네트워크 패킷을 가로 채울 수있는 사람은 누구나 읽을 수 있습니다.
2 단계 – 서버 안녕하세요
서버는 ServerHello 메시지로 ClientHello에 답장합니다. 클라이언트에게 TLS 버전을 사용하여 암호 제품군과 함께 선택한 압축 알고리즘과 함께 사용합니다. ServerHello는 서버 생성 랜덤 번호와 세션 식별자도 제공합니다. ServerHello도 ClearText로 전송됩니다.
ServerHello를 전송 한 직후 서버는 공개 키를 포함하는 인증서를 클라이언트에게 보냅니다. 다음과 같은 옵션 ServerKeyExchange 메시지가 이어집니다.
서버가 클라이언트가 클라이언트 인증서로 클라이언트를 식별하도록 요구하는 경우, 서버는 옵션 인증서 QuesterQuest 메시지를 통해 핸드 셰이크 에서이 시점에서이를 묻습니다.
마지막으로 서버는 클라이언트에게 ServerHelloDone 메시지를 보냅니다.
3 단계 – 서버 인증서를 확인하십시오
일반적으로 클라이언트는 서버가 서버를 확인할 수있는 인증서 또는 CA 루트 인증서가 있습니다’S 인증서는 진짜이며 서버에 등록’S IP 주소). 서버 인 경우’S 인증서는 알려져 있지 않으며, 클라이언트는 어쨌든 인증서를 수락 할 수있는 옵션 (잠재적으로 위험) 또는 연결을 끊을 수 있습니다. 이 메시지는 ClearText로 전송됩니다.
4 단계 – 클라이언트 응답
서버가 클라이언트로부터 인증서를 요청한 경우 클라이언트는 인증서를 보내고 ClientKeyExchange 메시지를 보냅니다.
ClientKeyExChange 메시지의 경우 클라이언트는 48 바이트로 구성된 프리미터 비밀이라고하는 것을 생성합니다. 이 비밀은이 메시지의 일부로 서버로 전송되지만 서버와 암호화됩니다’S 공개 키 (서버에서 얻은’S 인증서) 서버 만 개인 키로 해독 할 수 있도록 (메시지가 여전히 일반 텍스트로 전송되고 있기 때문에).
클라이언트와 서버가 프리미터 비밀을 공유 한 후에는 각각 마스터 비밀을 생성하기 위해 이전에 교환 된 임의의 값과 그 이후 세션 키 (후속 TLS 세션에서 데이터를 암호화하고 해독하는 데 사용되는 대칭 키)와 함께 사용합니다.
ChangeCiperspec 메시지는 ClientKeyExChange 메시지 후에 전송됩니다. 이 메시지는 서버에 새로 생성 된 세션 키를 사용하여 모든 후속 메시지가 암호화 될 것임을 나타냅니다. 완성 된 메시지가 뒤 따릅니다. 첫 번째는 암호화됩니다. 완성 된 메시지는 지금까지 전체 핸드 셰이크의 해시로 서버가 핸드 셰이크 전체에서 서버와 통신 한 클라이언트인지 확인할 수 있도록합니다.
5 단계 – 클라이언트 인증서를 확인하십시오
서버가 클라이언트의 인증서를 요청한 경우 올바른지 확인합니다.
6 단계 – 서버가 완료되었습니다
서버는 자체의 ChangeCiperspec 메시지를 통해 클라이언트의 완성 된 메시지에 응답하고 암호화 된 완제품 메시지가 이어집니다. 이를 통해 클라이언트가 핸드 셰이크 중에 커뮤니케이션 한 것과 동일한 서버인지 확인할 수 있습니다.
7 단계 – 보안 커뮤니케이션 설정
이 시점까지 모든 메시지가 암호화되어 클라이언트와 서버 간 네트워크를 가로 지르는 안전한 통신 채널이 설정되었습니다.
기록 및 경고
핸드 셰이크가 완료된 후 어떻게 데이터 포장 및 네트워크를 전송합니까?? 여기에는 레코드 프로토콜과 경고 프로토콜이 포함됩니다.
레코드 프로토콜
레코드 프로토콜은 데이터의 압축, 암호화 및 검증을 담당합니다. 전송할 모든 데이터는 레코드로 분할됩니다. 각 레코드는 헤더 바이트로 구성되며 프로토콜 버전, 전송 할 데이터의 길이 (페이로드라고 함) 및 페이로드 자체로 구성됩니다. 첫째, 압축이 합의 된 경우 데이터가 압축됩니다. 그런 다음 Mac을 계산하여 데이터에 추가합니다. Mac은 수신기가 레코드가 변조되지 않았는지 확인할 수 있도록합니다. 계산에는 발신자와 수신기가 모두 추적하는 시퀀스 번호가 포함됩니다. 마지막으로 데이터와 추가 된 Mac은 세션을 사용하여 암호화됩니다’S 암호화 키 및 결과는 레코드의 페이로드입니다. 수신 종료시 레코드가 해독되고 Mac은 레코드를 확인하기 위해 계산됩니다’S 데이터는 변조되지 않았습니다. 압축이 사용되면 압축 압축됩니다.
알림
오류가 발생하면 SSL/TLS는 클라이언트와 서버간에 오류 메시지를 전달할 수 있도록 경고 프로토콜을 정의합니다. 경고와 치명적인 두 가지 수준이 있습니다. 치명적인 오류가 발생하면 경고를 전송 한 후 연결이 닫힙니다. 경고가 경고 인 경우 세션이 계속되어야하는지에 대한 경고를받는 당사자에게 달려 있습니다. 중요한 경고 중 하나는 가까운 알림입니다. 어느 한 당사자가 세션을 닫기로 결정했을 때, 세션의 정상 종료하려면 Close Notify가 필요합니다. 일부 SSL/TLS 구현 이이 메시지를 보내지 않는다는 점은 주목할 가치가 있습니다. 단순히 연결을 종료합니다.
버전
SSL/TLS 내부 버전 번호는 공개적으로 버전 번호라고 할 수있는 것과 같이 해당하지 않습니다. 예를 들어, 3.1은 TLS 1에 해당합니다.0. 현재 사용중인 주요 버전이 여기에 표시됩니다.
내부 버전 번호가 종종 선호되므로 익숙해지는 것이 유용합니다.
SSL/TLS 취약점
TLS는 앞으로 몇 년 동안 인터넷에서 거래를 확보 할 성숙하고 널리 사용되는 안전한 네트워크 프로토콜입니다. 그러나 안전한 프로토콜과 마찬가지로 수년에 걸쳐 여러 가지 중요한 취약점이 발견되었습니다. 취약점은 계속 발견 될 것이며 최신 보안 패치가 적용되도록 TLS를 최신 상태로 유지하는 것이 중요합니다.
더 잘 알려진 취약점 중 일부와 이들이 해결 된 방법은 아래에서 설명합니다.
심장마다
Heartbleed는 TLS 소프트웨어에서 발견 된 가장 심각한 취약점 중 하나이며, 손상된 시스템의 서버 키, 사용자 세션 ID 및 사용자 비밀번호의 도난을 허용합니다. 그러나 SSL 프로토콜 결함이 아니라 OpenSSL에서 구현 버그 (과도한 버퍼로 알려짐)였습니다‘인터넷 전반에 걸쳐 널리 사용되는 무료 라이브러리. 수백만 개의 기계가 영향을 받았으며 수많은 성공적인 공격이보고되었습니다.
관련 버전의 OpenSSL을 사용하지 않는 소프트웨어 시스템은 영향을받지 않았습니다. OpenSSL은 빠르게 패치되었지만 수백만 개의 기계를 패치하는 데 시간이 걸립니다. 기계를 패치해야했을뿐만 아니라 서버 개인 키를 업데이트하고 사용자 암호를 변경하고 인증서가 다시 발행해야합니다. 1 년 후, 인터넷에 적절하게 수정되지 않은 시스템이 여전히 손상 될 수 있습니다.
Heartbled의 총 비용은 수억 달러의 범위에있는 것으로 추정됩니다.
푸들
푸들은 구형 SSL 프로토콜, SSL 3의 취약성입니다.0. 대부분의 시스템은 TLS 1을 사용합니다.0, 1.1 또는 1.2, TLS 프로토콜에는 여전히 SSL 3을 사용하는 이전 소프트웨어와 상호 운용성을 허용 할 수있는 낙진 조항이 있습니다.0. 따라서 푸들 공격은이 낙진 조항을 사용하여 서버를 SSL 3으로 다운 그레이드로 바보입니다.0.
가장 간단한 수정은 SSL 3을 비활성화하는 것입니다.클라이언트 및 서버에서 0. SSL 3.0은 1996 년에 출판되었으며 오랫동안 대체되어 왔으며 거의 20 년 후에이를 지원할 필요가 없습니다. 푸들은 가슴 흘린 것보다 훨씬 덜 심각한 취약성입니다.
RC4
RC4는 더 이상 안전한 것으로 간주되지 않는 널리 사용되는 TLS 암호입니다. RC4는 ARC4 또는 ARCFOUR라고도합니다 (RC4가 상표가 있기 때문에). 속도와 단순성은 RC4를 대중적으로 만들었지 만 최근 (2015 년 2 월) RFC7465는 더 이상 사용하지 않는 것이 좋습니다.
SSL/TLS 파일 전송 프로토콜 : FTPS
SSL/TLS의 가장 일반적인 사용 중 하나는 FTP로 알려진 안전한 파일 전송 형태입니다.
RFC 959에 정의 된 기존 FTP. 이것은 1985 년에 작성되었으며 1970 년대의 사양에 따라 이해할 수 있습니다. 이것은 대학과 군대가 인터넷의 주요 사용자였으며 보안은 오늘날의 우려가 아니었을 때였습니다.
결과적으로 FTP에서 사용자 이름과 암호가 (아직) 명확한 텍스트로 네트워크를 통해 전송되므로 TCP/IP 패킷을 스니핑 할 수있는 사람은 누구나 캡처 할 수 있습니다. FTP 서버가 인터넷에있는 경우 패킷은 공개 네트워크를 통과하며 공개적으로 사용할 수있는 것으로 간주되어야합니다.
Netscape가 안전한 소켓 층 (SSL)을 개발 한 것은 1990 년대가 되어서야 솔루션이 실용화되었습니다. 1996 년 RFC 초안은 FTP라는 FTP에 대한 확장을 설명하여 SSL 연결을 통해 FTP 명령을 사용할 수있게했으며 2005 년까지 공식적인 RFC로 개발되었습니다.
FileZilla와 같은 클라이언트와 Proftpd와 같은 서버가 구현 한 FTPS는 빠르게 인기를 얻었습니다.
암시 적 ftps
FTP에는 두 가지 형태의 FTP가 있습니다 – 암시 모드와 명시 적 모드. 암시 적 모드 FTP는 쓸모없고 널리 사용되지는 않지만 여전히 가끔 발생합니다.
암시 적 FTPS는 네트워크 연결을 보호하기위한 명시적인 명령이 없습니다. 대신 암시 적으로 그렇게합니다. 이 모드에서 FTPS 서버는 FTPS 클라이언트가 연결시 SSL/TLS 핸드 셰이크를 즉시 시작할 것으로 기대합니다. 그렇지 않으면 연결이 삭제됩니다. 암시 모드 연결의 표준 서버 포트는 990입니다 (FTP에 사용되는 표준 포트 21이 아님).
SSL/TLS 연결이 설정되면 표준 FTP 명령은 서버를 탐색하는 데 사용됩니다’S 파일 시스템 및 파일 전송. 연결이 안전하므로 비밀번호를 전송할 수 있고 EAVESDROPPERS에 의해 데이터를 검사 할 수 없습니다.
명시 적 FTP
명시 적 FTPS 모드에서 클라이언트는 Auth TLS 명령을 서버로 보내서 연결을 보장하도록 명시 적으로 요청해야합니다. 이 명령이 전송되면 SSL/TLS 핸드 셰이크가 암시 적 TLS와 같이 시작되며 명령 연결이 보안됩니다.
암시 적 모드에서 명시 적 모드 FTP를 사용하는 이점은 표준 FTP와 동일한 포트 번호를 사용할 수 있다는 것입니다 – 포트 21. 일반 FTP 사용자는 단순히 인증 명령을 보내지 않으므로 연결을 확보하지 않습니다. 서버 관리자는 무담보 파일 전송을 원하지 않으면 Auth 명령을 선택적으로 요구할 수 있습니다.
명시 적 모드 FTP는 항상 암시 적 모드보다 선호하여 사용해야합니다.
FTP의 단점
FTPS는 파일 내용 및 디렉토리 목록을 포함하여 데이터에 별도의 네트워크 연결을 사용하는 중 하나의 중요한 단점이 있습니다. 이것은 실제로 FTP 프로토콜의 일부입니다 – 명령은 이니셜을 통해 전송됩니다 “제어” 포트 21의 연결 및 데이터가 전송 될 때마다 전송을 위해 새로운 네트워크 연결을 설정해야합니다. 클라이언트와 서버는 포트 번호에 동의해야하며 연결을 열어야합니다.
암호화되지 않은 FTP를 사용하면 이것이 ISN입니다’너무 문제가됩니다. 짧은 시간 내에 너무 많은 전송이 이루어지면 네트워크 연결의 소진에 문제가있을 수 있습니다. 각 전송이 새로운 연결이 필요하고 운영 체제는 일반적으로 닫힌 연결을 자유롭게하려면 몇 분이 필요하기 때문에 작은 파일의 많은 전송은 결국 오류가 발생할 수 있습니다.
더 중요한 문제는 방화벽을 통과하는 것입니다. 방화벽은 일반적으로 포트 21을 통해 액세스 할 수 있도록 구성됩니다. 최신 방화벽은 또한 클라이언트와 서버 (Port 또는 PASV) 사이에 전송 된 명령을 검사하여 데이터 전송을 허용하도록 동적으로 열어야하는 포트를 결정할 수있을 정도로 영리합니다.
그러나 FTPS를 사용하면 명령이 암호화 된 채널에 있으며 방화벽은 검사 할 수 없습니다. 즉, 데이터 포트를 자동으로 열 수 없으므로 전송 및 디렉토리 목록이 실패합니다. 대신, 고정 된 범위의 포트는 미리 합의되고 클라이언트, 서버 및 방화벽에서 구성되어야합니다.
FTP의 미래
요즘 FTPS는 SFTP 또는 SSH 파일 전송 프로토콜에서 강력한 경쟁자를 보유하고 있습니다. 그것들은 완전히 다른 프로토콜이며, 다음 섹션에서 상대적 장점을 검토 할 것입니다. 그러나 FTP와 FTP는 거대한 설치 기반을 가지고 있으며 의심 할 여지없이 앞으로 몇 년 동안 계속 널리 사용될 것입니다.
SSH는 어떻게 작동합니까??
SSH 역사
1980 년 후반’S와 1990’S, Rlogin 및 Telnet과 같은 네트워크 도구는 일반적으로 원격 시스템, 일반적으로 Unix 플랫폼에 로그인하는 데 사용되었습니다. 이 도구는 사용자가 실제로 기계에있는 것처럼 원격 컴퓨터에서 명령을 실행할 수있는 명령 쉘을 열 수 있었으며 시스템 관리에 매우 유용했습니다.
한 가지 중요한 단점이있었습니다.이 도구 중 어느 것도 안전하지 않았습니다. 비밀번호는 일반 텍스트로 네트워크를 통해 전송되었습니다. 즉, 네트워크를 스니핑 할 수있는 사람은 원격 시스템의 자격 증명을 얻을 수 있습니다. 이 문제는 Helsinki University of Technology의 핀란드 연구원 인 Tatu Ylönen이 안전한 네트워크 프로토콜이 필요한 이유입니다. 1995 년 그는 SSH-1으로 알려진 SSH의 첫 번째 버전을 작성하여 프리웨어로 출시했습니다. 안전한 서버와 클라이언트로 구성되었습니다.
인기가 급격히 증가함에 따라 Ylönen은 SSH Communications Security를 설립하여 독점 제품으로 SSH를 마케팅하고 개발했습니다. 1999 년 Björn Grönvall은 이전 프리웨어 버전에서 작업하기 시작했으며 OpenBSD 팀은 자유롭게 이용 가능한 Openssh를 제작하기 위해 그의 작업에 자금을 지원했습니다. 포트는 곧 다른 많은 플랫폼으로 만들어졌으며 Openssh는 SSH의 가장 널리 알려져 있고 중고 버전으로 남아 있습니다.
2006 년 SSH 2.0은 RFC 4253에서 정의되었다. SSH-2는 SSH-1과 호환되지 않으며 보안 및 기능이 향상되어 SSH-1을 사용하지 않음.
SSH 개요
SSH는 안전한 네트워크 통신이 필요한 목적으로 모든 플랫폼에서 사용할 수있는 안전한 네트워크 프로토콜입니다. 일반적인 용도는 다음과 같습니다
- SSH 클라이언트와 같은 보안 원격 로그인 도구;
- SCP 및 SFTP 도구와 같은 보안 파일 전송; 그리고
- 보안 포트 전달 또는 보안 터널링.
SSH-2는 계층 아키텍처를 사용하며 전송 계층, 사용자 인증 레이어 및 연결 계층으로 구성됩니다.
전송 계층은 TCP/IP를 통해 실행되며 암호화, 서버 인증, 데이터 무결성 보호 및 선택적 압축을 제공합니다. 사용자 인증 계층은 클라이언트 인증을 처리하는 반면 연결 계층은 대화식 로그인, 원격 명령 및 전달 된 네트워크 연결과 같은 서비스를 제공합니다.
전송 계층
전송 계층은 메시지 기반이며 암호화, 호스트 인증 및 무결성 검사를 제공합니다. 바이너리 패킷 프로토콜을 통해 클라이언트와 서버간에 TCP/IP 사이에 메시지가 전송됩니다 “패킷” 데이터의 데이터는 아래 정의 된 형식으로 교환되며 각 패킷의 페이로드는 메시지입니다
UINT32 PACKET_LENGTH BYTE PADDING_LENGLE BYTE [N1] 페이로드; n1 = packet_length -Padding_length -1 바이트 [n2] 랜덤 패딩; n2 = padding_length byte [m] mac (메시지 인증 코드 -MAC); m = mac_length
Mac은 메시지 수신자가 메시지를 변경하지 않았는지 확인하는 Mac이기 때문에 중요한 필드입니다. 위에서 언급 한 무결성 검사. Mac은 패킷의 나머지 데이터를 통해 계산되며 클라이언트와 서버간에 설정된 공유 비밀과 양 당사자가 추적하는 시퀀스 번호를 사용합니다. Mac 은이 게시물에 설명되어 있습니다.
세션 설정
클라이언트와 서버 간의 세션은 어떻게 시작합니까?? TCP/IP 연결이 설정되면 각 측면이 식별 문자열을 보냅니다. 이 문자열은 다음 형식입니다
SSH-2.0-SoftwareVersion SP 주석 CR LF
여기 “sp” 공간을 의미합니다, “Cr” 캐리지 리턴 문자입니다 “LF” 라인 피드 문자입니다. 소프트웨어 버전은 공급 업체 버전이며 주석과 공간은 선택 사항입니다. 따라서 CompleteFTP의 경우 클라이언트가 서버에 연결하는 경우 다음 문자열을 수신합니다
SSH-2.0-completeftp_9.0.0
스트링은 필수 캐리지 리턴 및 라인 피드로 끝납니다 – 주석이 사용되지 않습니다.
식별 문자열이 교환되면 암호화에 사용되는 암호, 데이터 무결성에 사용되는 MAC 알고리즘, 암호화를 위해 일회성 세션 키를 설정하는 데 사용되는 주요 교환 방법, 인증에 사용되는 공개 키 알고리즘 및 최종적으로 사용되는 공개 키 알고리즘에 동의해야합니다. 클라이언트와 서버는 서로를 서로에게 보냅니다
바이트 ssh_msg_kexinit byte [16] 쿠키 (랜덤 바이트) 이름-리스트 kex_algorithms name-list kex_algorithms name-list server_key_key_key_algorithms name-list alcryption_algorithms_client_to_server name-list alcryption_algorithms_ser _to_client mac_algorithms mac_algorithms mac_algoRithms mac_algorithms mac_algorithme MS_SERVER_TO_CLIEIN NAME-LIST COMPREATIC_ALGORITHMS_CLIENT_TO_SERVER NAME-LIST COMPREATIC_ALGORITHMS_SERVER_TO_TO_CLIENT NAME-LIST LANGER_CLIENT_TO_SERVER NAME-LIST 언어 _SERVER_TO_CLIENT BOOLEAN FIRST_KEX_PACKET_FOLLOWS UINT32 0 (미래 extension을위한 예약)
이 메시지는 위에서 설명한 형식의 이진 프로토콜 패킷의 페이로드입니다. 알고리즘의 이름 목록은 쉼표로 구분됩니다. 클라이언트는 선호 순서대로 알고리즘 목록을 보내고 서버는 지원하는 알고리즘 목록을 보냅니다. 클라이언트의 첫 번째 지원 알고리즘’S 기본 설정은 선택된 알고리즘입니다. 두 메시지 모두 주어지면 각 측면은 어떤 알고리즘을 사용할 수 있는지 알아낼 수 있습니다.
SSH_MSG_KEXINIT 이후 선택된 주요 교환 알고리즘으로 여러 메시지가 교환 될 수 있습니다. 최종 결과는 공유 비밀, K 및 Exchange 해시의 두 가지 값입니다. 이들은 암호화 및 인증 키를 도출하는 데 사용됩니다. SSH_MSG_NEWKEYS는 이러한 협상의 끝을 나타 내기 위해 전송되며 모든 후속 메시지는 새로운 암호화 키 및 알고리즘을 사용합니다.
SSH-2 연결이 설정되면 클라이언트가 “서비스” (일반적으로 인증 프로세스를 시작하려면 ssh-userauth) ssh_msg_service_request 메시지와 함께.
인증 계층
다음 단계는 클라이언트가 서버에 자신을 식별하고 인증하는 것입니다. 이것은 전송 계층 위에서 실행되는 사용자 인증 계층을 통해 관리됩니다. 즉, 사용자 인증 메시지가 전송 계층을 사용하여 암호화되고 교환됩니다.
사용자 인증은 클라이언트가 a “서비스” SSH-Userauth 서비스 요청. 요청을 허용하여 서버가 응답하는 경우 클라이언트는 사용자 이름과 인증 방법을 포함하는 인증 요청을 보냅니다.
가능한 여러 인증 방법이 있으며 사용되는 방법은 클라이언트 및 서버에 따라 다릅니다’그것에 대한 지원. 가장 인기있는 방법은 비밀번호 인증입니다. 다른 하나는 홍보 인증입니다. 일반적으로 클라이언트는 메소드를 제안하고 서버는 해당 메소드를 수락하거나 거부합니다.
사용자가 부르는 사용자의 비밀번호 인증 요청의 예 “Enterprisedt” 아래에 표시됩니다
바이트 ssh_msg_userauth_request 문자열 “Enterprisedt”[사용자 이름] 문자열 “ssh-userauth”[서비스 이름] 문자열 “암호”[인증 방법] 부울 거짓 문자열 “mypassword”[user ‘s password]
서버는이 사용자에 대해 전송 된 비밀번호를 사용자에게 저장 한 세부 사항에 대해 확인합니다. 서버는 사용자를 저장하지 않습니다’유효성 검사를위한 실제 비밀번호이지만 암호를 얻기 위해 리버스 엔지니어링 할 수없는 암호의 암호화 해시.
사용자 인증 요청이 거부 된 경우 (예 : 잘못된 암호가 제공된 경우) 서버에서 실패 메시지가 전송되며 시도 할 수있는 대체 인증 목록을 제공합니다.
보내는 것이 일반적입니다 “없음” 초기 인증 방법으로, 서버는 일반적으로 사용 가능한 모든 인증 방법의 목록이 포함 된 실패 메시지로 응답합니다. 예제 응답 “없음” 아래에 표시됩니다
바이트 ssh_msg_userauth_failure 이름 목록 암호, publickey boolean false (부분 성공 플래그)
여기서 서버는 클라이언트에게 암호 또는 공개 키 인증을 사용할 수 있음을 알리고 있습니다.
비밀번호 인증 요청이 성공하면 서버는 다음과 같이 성공 메시지를 반환합니다
바이트 ssh_msg_userauth_success
이 시점에서 인증이 완료되고 다른 서비스를 요청할 수 있습니다. 여기에는 TCP/IP 전달 요청 및 터미널 액세스 용 채널, 프로세스 실행 및 SFTP와 같은 하위 시스템이 포함될 수 있습니다.
연결 계층
SSH-2의 마지막 조각’S 계층 아키텍처는 연결 계층으로, 인터랙티브 세션 및 전송 계층 상단의 포트 전달과 같은 네트워크 서비스를 제공하여 필요한 보안을 제공합니다.
일단 설립되면 SSH 연결은 하나 이상의 SSH 채널을 호스팅 할 수 있으며, 연결을 통해 다중화 된 논리 데이터 파이프입니다. 클라이언트는 동일한 서버에 대한 하나의 연결에서 여러 채널을 열고 다른 채널에서 다른 네트워크 작업을 수행 할 수 있습니다. 실제로 SSH 구현은 연결에서 여러 채널을 거의 사용하지 않으며 각 채널에 대한 새 연결을 선호합니다.
SSH 채널의 중요한 기능은 흐름 제어입니다. 수신자가 수신 할 준비가되었다고 표시했을 때 데이터는 채널을 통해서만 전송 될 수 있습니다. 창의 크기는 채널이 열릴 때 수신자가 설정하고 데이터가 전송 될 때 창 크기가 줄어 듭니다. 주기적으로 수신자는 창 크기를 늘리기 위해 메시지를 보냅니다.
대화식 세션을 열는 데 사용되는 SSH_MSG_CHANNEL_OPEN 메시지는 다음과 같습니다. 이 세션은 이후 터미널 세션, 원격 명령을 실행하거나 SFTP와 같은 서브 시스템을 시작하는 데 사용될 수 있습니다.
바이트 ssh_msg_channel_open 문자열 “세션”UINT32 발신자 채널 UINT32 초기 창 크기 UINT32 최대 패킷 크기
초기 창 크기는이 메시지의 수신자가 발신자에게 보낼 수있는 바이트 수를 설정하는 반면, 최대 패킷 크기는 단일 메시지에서 수락하는 가장 큰 데이터입니다.
이 메시지 수신자는 요청 된 채널을 열 준비가 된 경우 SSH_MSG_CHANNEL_OPEN_CONFIRMATION 메시지로 응답합니다
바이트 SSH_MSG_CHANNAL_OPEN_CONFIRMATION UINT32 수신자 채널 UINT32 발신자 채널 UINT32 초기 창 크기 UINT32 최대 패킷 크기
채널이 성공적으로 열리면 데이터를 교환 할 수 있으며 채널 별 요청이 전송 될 수 있습니다. 클라이언트 또는 서버의 슬라이딩 윈도 크기가 너무 작아지면 창의 소유자는 ssh_msg_channel_window_adjust 메시지를 보냅니다
바이트 ssh_msg_channel_window_adjust uint32 수신자 채널 UINT32 바이트 추가
데이터는 SSH_MSG_CHANNEL_DATA 메시지를 통해 채널을 통해 전송됩니다. 데이터를 사용하는 방법은 설정된 채널 유형에 따라 다릅니다
바이트 ssh_msg_channel_data uint32 수신자 채널 문자열 데이터
채널 요청은 채널을 통해 특정 작업을 수행하는 데 사용됩니다. 일반적인 요청에는 쉘 시작 또는 원격 명령 실행이 포함됩니다. 예를 들어, 원격 쉘은 아래에 표시된 요청에 따라 시작됩니다
바이트 ssh_msg_channel_request uint32 수신자 채널 문자열 “쉘”부울 원을 원합니다
원격 명령은 다음 요청에 의해 실행됩니다
바이트 ssh_msg_channel_request uint32 수신자 채널 문자열 “exec”boolean want reply string 명령
마지막 으로이 요청에 따라 SFTP 서브 시스템을 열 수 있습니다
바이트 ssh_msg_channel_request uint32 수신자 채널 문자열 “서브 시스템”부울 원하는 답장 문자열 “sftp-server”
서브 시스템은 서버 시스템에서 사전 정의 된 원격 명령 세트입니다. 가장 일반적인 것은 SFTP로 파일을 전송 및 조작하는 명령을 제공합니다. 서브 시스템 명령 (SFTP 프로토콜 포함)은 SSH를 통해 실행됩니다.이자형. 서브 시스템 명령에 대한 데이터는 ssh_msg_channel_data 메시지에서 전송됩니다.
이 메시지 중 하나가 클라이언트 또는 서버에 도착하면 처리를 위해 서브 시스템으로 전달됩니다.
클라이언트 또는 서버가 채널 사용을 완료 한 후에는 닫아야합니다. ssh_msg_channel_eof 메시지는이 메시지의 방향으로 더 이상 데이터가 전송되지 않음을 나타내도록 전송됩니다. ssh_msg_channel_close 메시지는 이제 채널이 닫혀 있음을 나타냅니다. 수신자는 아직 보내지 않은 경우 ssh_msg_channel_close로 답장해야합니다. 닫으면 채널을 다시 열 수 없습니다.
SSH 파일 전송 프로토콜 : SFTP
SSH와 함께 사용되는 가장 일반적인 서브 시스템은 SFTP로 파일을 전송 및 조작하는 명령을 제공합니다. SFTP.
SFTP 서브 시스템은 SSH 전송 계층을 통해 실행되지만 자체적으로 정교한 메시지 기반 프로토콜입니다. SFTP 메시지는 전송 계층의 데이터 필드로 전송됩니다’sssh_msg_channel_data 메시지
SFTP 메시지는 다음과 같이 표준 형식입니다
UINT32 길이 바이트 타입 UINT32 요청 -ID . 특정 필드 유형…
첫 번째 필드는 길이 필드를 제외하고 메시지의 길이이며 다음은 메시지 유형입니다. 세 번째 필드는 요청 ID입니다 – 클라이언트에서 전송 된 모든 요청에는 요청 ID가 있으며 서버’S 답장에는 해당 요청 ID가 포함되어야합니다.
유형 ID와 함께 더 중요한 SFTP 메시지 중 일부는 다음과 같습니다
SSH_FXP_INIT 1 SSH_FXP_VERSION 2 SSH_FXP_OPEN 3 SSH_FXP_CLOSE 4 SSH_FXP_READ 5 SSH_FXP_WRITE 6 SSH_FXP_STATUS 101 SSH_FXP_DATA 103
SSH_FXP_INIT는 클라이언트가 SFTP 세션을 시작하기 위해 보낸 첫 번째 메시지이며 서버는 SSH_FXP_VERSION으로 응답하여 지원하는 버전을 나타냅니다.
ssh_fxp_open은 서버가 파일을 열도록 요청합니다 (또는 존재하지 않으면 선택적으로 작성)
ssh_fxp_close는 파일을 닫습니다. ssh_fxp_read는 파일에서 특정 바이트 범위를 읽도록 요청하고 서버는 요청 된 바이트를 포함하는 ssh_fxp_data로 응답합니다. ssh_fxp_write는 파일에 데이터를 작성하는 데 사용되며 필드 중 하나는 쓸 데이터 (파일에 오프셋)입니다.
위의 명령이 실패하면 SSH_FXP_STATUS가 발생한 오류 유형을 나타내는 오류 코드와 함께 반환됩니다. 또한 ssh_fxp_write에 대한 응답으로 성공적인 쓰기를 알리는 데 사용됩니다.
파일 제거 (ssh_fxp_remove), 파일 이름 바꾸기 (ssh_fxp_rename) 및 디렉토리 생성 및 제거와 같은 다른 표준 파일 및 디렉토리 작업에 대한 명령도 있습니다 (ssh_fxp_mkdir, ssh_fxp_rmdir). 디렉토리는 (ssh_fxp_opendir)를 열고 SSH_FXP_READDIR 요청을 보내면서 읽습니다. 다시, SSH_FXP_STATUS는 이러한 요청의 성공 또는 실패를 나타내는 데 사용됩니다.
SFTP 세션을 종료하기위한 특정 SFTP 메시지가 없습니다. 대신 클라이언트는 사용중인 SSH 채널을 닫습니다.
SFTP는 전통적인 FTP와 완전히 다른 프로토콜이라는 점에 유의해야합니다.이자형. SSH 연결을 통해 전송 된 FTP 명령이 아닙니다. 대조적으로, FTPS는 SSL/TLS 연결을 통해 전송 된 FTP 명령입니다. 두 프로토콜은 파일 전송을위한 안전한 프로토콜이므로 쉽게 혼란스러워합니다.
SFTP 대 ftps
우리는 위의 FTP와 SFTP 작동 방식을 설명했습니다. 기본적으로 두 프로토콜은 파일 전송을 안전하게 보안하고 파일 시스템의 원격 조작을 보장합니다.
그러나 이들은 완전히 다른 프로토콜이며 보안 파일 전송 솔루션을 구현하는 사람들은 사용할 프로토콜을 결정해야합니다.
기존 사용은 당연히 중요한 고려 사항입니다. SFTP 및/또는 SSH가 조직의 다른 영역에서 이미 사용되는 경우 SFTP를 사용하는 것이 현명합니다. 조직 내 기존 지식과 기술과 기술 인프라를 활용할 수 있습니다. 마찬가지로 FTP 및/또는 FTPS가 이미 다른 곳에서 사용 된 경우 FTP를 사용하는 것이 가장 좋습니다.
프로젝트 요구 사항은 또한 프로토콜을 지시 할 수 있습니다. 서버 측 솔루션이 구현되는 경우 클라이언트가 특정 프로토콜로 제한되어 있으므로 결정을 내릴 필요가 없습니다.
그러나 시작점이 완전히 깨끗한 슬레이트이고 어떤 프로토콜을 사용할 수 있는지 제약이 없다면? 명확한 승자가 있습니까??
SFTP- 명확한 승자
예, SFTP입니다. 몇 년 전, 그러한 결정은 주로 대부분의 조직에서 FTP 프로토콜의 지배로 인해 간단하지 않았습니다. 이제 클라이언트와 서버 소프트웨어는 SFTP 및 FTP 모두에서 널리 사용할 수 있습니다. 실제로 CompleteFTP 지원과 같은 많은 응용 프로그램.
이것은 순전히 기술적 인 근거에서 결정을 내릴 수 있으며 SFTP.
SFTP는 방화벽에서 더 좋습니다
FTP는 방화벽으로 작업하는 데 고통 스러울 수 있습니다. 디렉토리 목록 및 파일 전송은 포트 21의 제어 채널과 별개의 새로운 네트워크 연결에서 이루어지기 때문입니다. 기본적으로 방화벽은 이러한 연결을 FTPS에서 허용하지 않습니다 (방화벽이 네트워크 트래픽을 검사하고 적절한 포트를 미리 열 수 있기 때문에 일반적으로 FTP에서 작동하지만). 대신 방화벽과 서버는 데이터 전송을 위해 특정 범위의 포트에 대해 구성되어야하며 복잡해질 수 있습니다.
대조적으로, SFTP는 방화벽에서만 작동합니다. 데이터 및 명령은 모두 표준 포트 22를 통해 전송되며 일반적으로 기본적으로 방화벽으로 활성화됩니다. 이것은 FTP보다 중요한 이점입니다.
sftp는 그다’T 인증서를 사용하십시오
FTPS는 인증서를 사용하여 클라이언트에 서버를 식별합니다. 클라이언트가 올바른 서버에 연결하고 있는지 확인하는 방법이므로 서버 식별이 중요합니다. 그러나 인증서는 증명서 기관에서 발행해야합니다. 인증서를 얻는 것은 비용이 많이 들고 시간이 많이 걸릴 수 있습니다.
sftp는 그다’T 사용 인증서 – 서버는 공개 키에 의해 식별됩니다 (이것은 인증서에 포함 된 것이므로 궁극적으로 동일한 메커니즘을 사용합니다). 따라서 클라이언트가 서버의 공개 키를 가지고있는 한 서버가 올바른지 확인할 수 있습니다. 서버’S의 공개 키 (인증서와 달리)는 조직에서 생성 할 수 있으며 인증 기관이 필요하지 않습니다. 이것은 서버를 높이고 실행하는 데 필요한 관리의 양을 크게 줄입니다.
인증서를 발급하기위한 인증 기관과 같은 인정 된 조직을 보유하는 데는 몇 가지 장점이 있지만, 특히 내부 프로젝트에는 필요한 시간이 많이 필요하지 않습니다.
SFTP 사용에 대한 단점이 있습니까??
인증서 권한을 인식하려면 인증서가 없을 수 있지만 SFTP의 주요 단점은 구현하기 어려운 복잡한 프로토콜이라는 것입니다. SFTP 클라이언트 또는 SFTP 서버를 작성하는 것은 쉬운 일이 아닙니다.
그러나 이것은 인프라의 일환으로 SFTP를 사용하는 조직에 영향을 미치지 않을 것입니다. 다양한 클라이언트와 서버가 다양한 플랫폼에서 제공되며 가장 적합한 응용 프로그램 만 선택하면됩니다. 모든 클라이언트와 서버는 상호 작용해야하므로 제품 선택에 상당한 위도가 있습니다. 프로토콜에 추가 기능이 최종 선택을 지시 할 수 있습니다.
결론
이 컨텐츠는 SSL/TLS 및 SSH가 네트워크를 통해 데이터를 전송하는 데 도움이되는 방법, 특히 FTP 및 SFTP 프로토콜을 설명했습니다. 기능은 비슷하지만 FTP와 SFTP는 구현에서 크게 다릅니다. 일대일 비교에서 SFTP는 조직의 기술 인프라에서 두 프로토콜을 모두 지원하는 것이 현명 할 수 있지만 SFTP는 최상위에 나옵니다.
기타 기술 기사
- 관리되는 파일 전송 (MFT)?
- sftp는 무엇입니까??
- FTP는 무엇입니까??
- ftps는 무엇입니까??
- FTPS 대 SFTP
SSL vs SSH- 기술적이지 않은 비교
SFTP와 FTP가 기본 프로토콜로부터 보안을 얻는다는 것을 알고 있습니까?? 오늘 SSH와 SSL의 유사점과 차이점을 발견하십시오!
개요
가장 널리 사용되는 보안 파일 전송 프로토콜 인 SFTP 및 FTP는 기본 프로토콜에서 보안을 얻습니다. SSH의 SFTP 및 SSL의 FTPS. 둘을 비교해 봅시다.
과거에는 네트워크를 통해 파일을 전송하는 인기있는 방법이 하나뿐이었는데, FTP는 단순히 파일 전송 프로토콜을 나타냅니다. FTP는 대량 파일 전송을 지원하고 사용자가 원격 디렉토리를 탐색하고 디렉토리 생성, 디렉토리를 삭제하며 로컬 파일 시스템에서 수행 한 것과 유사한 몇 가지 다른 작업을 수행 할 수 있습니다.
FTP는 TCP 기반 프로토콜입니다. 따라서 LAN 또는 인터넷을 통해 파일을 다운로드/업로드하는 데 매우 유용 할 수 있습니다. 그러나 FTP는 인터넷 사용이 일부 조직으로 제한되었고 네트워크 기반 위협이 존재하지 않는 시점에 설계되었습니다.
오늘날, 스니퍼 공격, 무차별 인 및 기타 형태의 사이버 공격을 통해 이미 여러 위협이 존재하고 FTP 연결이 손상 될 수 있습니다. 이러한 위협으로부터 파일 전송을 보호하기 위해 보안 파일 전송 프로토콜이 개발되었습니다. 이 프로토콜 중 2 개는 광범위한 채택을 얻었습니다 -FTPS 및 SFTP.
FTP는 실제로 SSL/TLS (Secure Sockets Layer/Transport Layer Security)로부터 보호를 받고 SFTP는 SSH (Secure Shell)에서 자체적으로 얻습니다.
SSH와 SSL의 유사성
보안 속성을 비교할 때 SSH와 SSL이 매우 강한 유사성을 가지고 있음을 알 수 있습니다. 둘 다 데이터 인 암호화, 서버 인증, 클라이언트 인증 및 데이터 무결성 메커니즘을 제공합니다.
데이터 인 모션 암호화
데이터 인 모션 암호화는 도청자가 네트워크를 통해 전송되는 데이터를 보지 못하게하는 보안 기능입니다. 다시 말해, 전송 된 데이터를 기밀로 유지합니다. SSH와 SSL 모두에서 지원되며 일반 텍스트 데이터를 암호 텍스트로 알려진 것으로 변환하여 행동합니다.
암호화 된 연결에서 암호 텍스트를 볼 때 모든 도청자는 이해할 수없는 문자열이 될 것입니다.
이 두 스크린 샷은 암호화되지 않은 연결과 암호화 된 연결을 스니핑 할 때 도청자가 보는 것을 보여줍니다. 암호화되지 않은 연결이 사용자 이름과 비밀번호를 숨기지 못하는 방법에 주목하십시오. 암호화되지 않은 연결에서 해당 로그인 자격 증명은 이미 이해할 수 없습니다.
암호화되지 않은 연결 (e.g. FTP)
암호화 된 연결 (e.g. sftp 또는 ftps)
SSH와 SSL은 모두 대칭 키 암호화로 알려진 데이터-인 모션 암호화를 제공합니다. 이런 종류의 암호화는 암호화 및 암호 해독에 사용되는 공유 키를 사용합니다. 일부 일반적인 대칭 키 암호에는 AES, 3DES, Blowfish, Twofish 및 RC4가 포함됩니다.
서버 및 클라이언트 인증
무의식적으로 가짜 서버 나 악성 클라이언트에 연결되면 암호화 된 연결이 쓸모가 없습니다. SSH 및 SSL은 대칭 암호화를 사용하여 전송 된 데이터의 기밀성을 유지하지만 인증을 위해 다른 형태의 암호화를 사용합니다. 인증은 한 당사자가 다른 당사자가 실제로 그것이 주장하는 사람인지 확인할 수 있습니다.
인증을 구현하려면 SSH 및 SSL을 사용하여 비대칭 암호화를 사용합니다.케이.ㅏ. 공개 키 암호화. 인기있는 공개 키 암호화 알고리즘은 RSA, DSA 및 ECDSA이며, 모두 SSH와 SSL이 지원합니다.
암호화 및 암호 해독에 단일 키를 사용하는 대칭 암호화와 달리 비대칭 암호화는 두 가지 키를 사용합니다. 공개 키와 개인 키.
클라이언트가 공개 키 암호화를 사용하여 서버를 인증 할 수 있습니다. 이것을 서버 인증이라고합니다. 서버 인증은 클라이언트 애플리케이션이 부주의하게 연결 한 다음 합법적 인 서버를 가장하는 악성 서버와 거래하는 것을 방지합니다.
반대로, 공개 키 암호화는 서버에서 클라이언트를 인증하는 데 사용될 수도 있습니다. 이를 클라이언트 인증이라고합니다. 기사 SFTP 키는 무엇입니까? 클라이언트 인증 및 공개 키 암호화에 대한 좋은 소개 포함.
데이터 무결성 메커니즘
민감한 정보를받을 때 데이터 무결성은 데이터 기밀만큼 중요합니다. 받은 데이터가 원래 발신자가 전송 한 데이터와 정확히 동일한 데이터인지 확인하고 싶을 것입니다.
특히 기업은 인터넷을 통해 거래를 수행 할 때 데이터 무결성에 대한 높은 수준의 보증이 필요합니다. 변조 된 데이터는 비즈니스 프로세스에 부정적인 영향을 줄 수 있으며 사기 활동의 징후 일 수도 있습니다.
데이터 무결성 메커니즘은 트랜잭션 파티가 전송 된 메시지가 길을 따라 변경되지 않았는지 확인할 수 있도록합니다. SHA1, SHA256 (및 기타 버전의 SHA) 및 MD5와 같은 MAC (메시지 인증 코드) 알고리즘은 일반적으로 전송 된 메시지에서 데이터 무결성 검사를 수행하기 위해 SSH 및 SSL에 의해 일반적으로 사용됩니다.
해싱 이해를 이해하는 기사에는 주제에 대한 멋진 토론이 포함됩니다.
SSL과 SSH의 차이점
SSL/TLS와 SSH의 가장 눈에 띄는 차이점 중 하나는 SSL이 정상적으로 (예, 예외가있을 수 있음) x를 사용한다는 것입니다.SSH는 서버 및 클라이언트 인증을위한 509 디지털 인증서. SSL은 디지털 인증서를 사용하기 때문에 결과적으로 공개 키 인프라 (PKI)의 존재와 인증 기관 (CA)의 참여도 필요합니다.
자체 서명 된 인증서로 알려진 것을 사용할 수는 있지만 CA가 없기 때문에 SSL과 매우 유사하게 SSL이 발생하지만 권장되는 관행은 아닙니다. 자체 서명 된 인증서는 대규모를 제외하고 조직 내 거래에서만 허용됩니다 (E.g. 전 세계적으로 분산 된) 조직.
또 다른 큰 차이점은 SSH에 더 많은 기능이 내장된다는 것입니다. 예를 들어, 자체적으로 SSH는 사용자가 서버에 로그인하고 명령을 원격으로 실행할 수 있습니다. SSL에는이 기능이 없습니다. 다른 프로토콜과 쌍을 이루어야합니다 (E.g. 유사한 기능을 갖기 위해 HTTP, FTP 또는 WebDAV).
SSH는 또한 연결 멀티플렉싱, 흐름 제어, 터미널 관리 및 기타 기능을 쉽게 지원합니다. 물론 이러한 추가 기능은 더 이상 SFTP 및 FTP와 관련하여 SSL과 SSH를 비교하기 시작한 원래 토론에 해당하지 않습니다.
그래서 우리가 더 이상 멀어지기 전에 여기서 끝내자.
시작하다
FTPS 및 SFTP 및 기타 프로토콜을 지원하는 파일 전송 서버를 사용해 보시겠습니까?? 오늘 JScape MFT 서버의 무료 완전 기능 평가판을 사용해보십시오.
인기있는 기사
명령 줄에서 SFTP 공개 키 인증 설정
6 분 읽기 – 2022 년 12 월 11 일
SFTP는 공개 키를 사용하여 클라이언트를 인증 할 수 있습니다’비밀번호가 필요합니다. 명령 줄에서 온라인으로 설정하는 방법에 대해 알아보십시오. 기사를 읽으십시오
활성 대. 수동 FTP 단순화 : FTP 포트 이해
7 분 읽기 – 2022 년 12 월 11 일
FTP 서버에 연결하는 데 문제가있는 경우 전송 모드를 확인하십시오. Jscape가 Active & Passive FTP의 차이를 이해하도록 도와주십시오. 기사를 읽으십시오
활성 활성 대 VS. 능동적 인 권리가 높은 고용성 클러스터링
3 분 읽기 – 2022 년 12 월 11 일
가장 일반적으로 사용되는 고 가용성 클러스터링 구성은 활성 활성 및 활성 패러스입니다. 온라인 두 가지의 차이점을 배우십시오! 기사를 읽으십시오
Windows FTP 스크립트를 사용하여 파일 전송을 자동화합니다
4 분 읽기 – 2022 년 12 월 11 일
Windows FTP 스크립트를 사용하여 파일 전송을 자동화하는 방법에 대해 알아보십시오. 이 게시물은 FTP 스크립트가 무엇인지 설명하고 파일을 전송하기 위해 간단한 스크립트를 만드는 방법에 대해 설명합니다. 기사를 읽으십시오
SSH는 TLS 또는 SSL을 사용합니까?
об йтоэ странице
м е р р регистрировали подо 착취 ay rzа ф징퍼, исход 넘추 타 ay сети. с пом거나 ю это인지 страницы м주는 сможем определить, что з просы отправляете именно, а не робот. почему это могло произойти?
эта страница отобр은 Âется в тех Â сл 나아가 · 추, ∈огда автомати인지 скими системи Google регтрирр곽막우 ся 테 추 법구추 추 님. котор ое нарушают условия использования. странира перестанет отобр은 жаться после того, как эти запросы прекратся. до отого момента для использования слу 갑기 Google необ 영향.
источником запросов может служить вредоносное по, подключаемые модули браузера или скрипт, насое 밑 밑 밑보관 сзлку ыапросов. если вл используете общий доступ в интернет, проблема 갑새 갑새 딘 악 с сомпером с с с с с саким 테 IP-адесом → Â 궤. обратитесь к своему системному администратору. подроб 변태.
проверка по слову может татак뿐 아니라 자기 появляться, если вы В 갑 갑격적 В Â водите слож ные запросы, об협 ораспронон혁 ™ rапротототототототото술도 있습니다. емами, или вводите запросы очень часто.
SSH vs SSL : 그들 사이의 차이점과 유사성 [Minitool 팁]
SSH와 SSL의 차이점은 무엇입니까?? 어느 것이 더 낫습니다? 이 질문을 찾으려고한다면’ 답,이 게시물은 필요한 것입니다. Minitool 의이 게시물은 SSH 대 SSL에 대한 정보뿐만 아니라 그들의 정의를 제공합니다.
SSH는 무엇입니까?
SSH는 무엇을 의미합니까?? SSH는 원격 컴퓨터와의 보안 통신 방법 인 Secure Shell이라고도합니다. SSH는 다른 시스템의 작동 쉘과 상호 작용하여 명령을 원격으로 실행하는 데 사용됩니다.
SSH는 원래 UNIX 기반 컴퓨터에서만 사용할 수 있지만 이제 Windows에서 사용할 수 있습니다. SSH는 두 원격 컴퓨터 사이에 터널을 만드는 암호화 프로토콜입니다. 아마도이 게시물 – Windows 10에서 SSH 클라이언트 및 서버를 설정하는 방법 [전체 가이드]은 필요한 것입니다.
SSL/TLS 란 무엇입니까?
SSL이란 무엇입니까?? SSL 및 TLS는 웹 사이트의 보안을 보호하는 메커니즘입니다. SSL과 TLS는 거의 동일한 작업을 수행하지만 TLS는 점차 네트워크 구현에서 SSL을 대체합니다. 그들은 인증 기관이 생성 한 디지털 서명을 사용하여 귀하와 제공자 간의 신뢰를 가능하게합니다.
SSH 대 SSL
SSH 및 SSL/TLS는 일반적으로 다른 사용법을 가지고 있습니다. SSH는 일반 인터넷 사용자가 처리 할 필요가없는 작업을 수행하는 데 사용됩니다. 반면에 일반 인터넷 사용자는 SSL/TLS를 사용하고 있습니다. 다음은 SSL 대 SSH에 대한 정보입니다.
유사성
자,하자’s SSH와 SSL의 유사성을 참조하십시오. 먼저 SSH와 SSL은 모두 같은 편지로 시작하는 3 자리 약어입니다. 다음으로, 이들은 안전한 연결에 사용되는 두 프로토콜입니다. 마지막으로, 둘 다 암호화를 사용하여 두 네트워크 장치 사이에 전달 된 데이터를 보호합니다.
차이
지금, 당신은 SSH와 SSL의 유사점을 알고 있습니다. 그런 다음하자’s SSH와 SSL의 차이점을 참조하십시오.
1. SSH는 포트 22에서 실행되며 SSL은 포트 443에서 실행됩니다.
2. SSH는 네트워크 터널을 기반으로하며 SSL은 인증서를 기반으로합니다.
삼. 기술적으로 SSH는 컴퓨터 네트워크를 보호하는 데 사용되며 SSL은 온라인 데이터 전송을 보호하는 데 사용됩니다.
4. SSH는 사용자 이름/비밀번호 인증 프로세스를 사용하여 안전한 연결을 설정하지만 SSL은 고려하지 않습니다.
5. SSL은 신용 카드 및 은행과 같은 주요 정보를 안전하게 전송하는 데 사용됩니다. SSH는 인터넷에서 안전하게 명령을 실행하는 데 사용됩니다.
6. SSL은 일반적으로 (예외 제외) x를 사용합니다.서버 및 클라이언트 인증을위한 509 개의 디지털 인증서, SSH는 그렇지 않습니다.
7. SSL은 브라우저와 서버 간의 통신을 암호화하는 데 사용됩니다. 반면 SSH는 인터넷의 두 컴퓨터 간의 통신을 암호화하는 데 사용됩니다.
8. SSL에서 커뮤니케이션은 개인/공개 키 쌍에 의해 인증됩니다. SSH에서 커뮤니케이션은 개인/공개 키 쌍 또는 사용자 이름/비밀번호 쌍을 통해 인증됩니다.
9. 또 다른 주요 차이점은 SSH에 SSL보다 더 많은 내장 기능이 있다는 것입니다. 서버에 로그인하고 원격으로 명령을 실행하는 데 도움이되며 SSL 은이 기능이 없습니다. 이 기능을 달성하려면 다른 프로토콜 (HTTP, FTP)과 페어링해야합니다.
HTTP 오류를 해결하는 5 가지 방법 401 무단
무언가를 검색하기 위해 브라우저를 열 때 HTTP 오류 401 무단으로 나올 수 있습니다. 이 게시물은이 401 오류를 해결하는 방법을 보여줍니다.
마지막 단어
다음은 SSH 대 SSL에 대한 모든 정보입니다. 이 게시물을 읽은 후 SSH와 SSL이 무엇인지 알아야합니다. 이 게시물에서 SSH와 SSL의 유사점과 차이점이 있음을 알고 있습니다.
- 페이스 북
- 트위터
- 레딧
저자에 대해
Daisy는 영어 전공을 졸업 한 후 Minitool에 편집자로 합류했습니다. 그녀는 데이터 및 시스템 백업, 복제 디스크 및 파일 동기화 등에 관한 기사 작성을 전문으로합니다. 그녀는 또한 컴퓨터 지식 및 컴퓨터 문제에 관한 기사를 작성하는 데 능숙합니다. 일상 생활에서 그녀는 달리기를 좋아하고 친구들과 함께 놀이 공원에가는 것을 좋아합니다.
