Menu Close
Settings Close

Language and Page Formatting Options

1.5. SSL/TLS 및 인증서

SSL/TLS는 두 시스템에서만 알려진 대칭 키를 사용하여 두 시스템 간의 네트워크 트래픽을 암호화합니다. 대칭 키의 안전한 교환을 위해 SSL/TLS는 키 쌍을 사용하는 암호화 방법인 PKI(Public Key Infrastructure)를 사용합니다. 키 쌍은 별도의 두 개의 암호화 키, 즉 공개 키와 개인 키로 구성됩니다. 공개 키는 모든 당사자와 공유되며 데이터를 암호화하는 데 사용됩니다. 개인 키는 비밀로 유지되며 공개 키를 사용하여 암호화된 데이터를 해독하는 데 사용됩니다.

클라이언트에서 대칭 키를 교환하기 위해 보안 연결을 요청하면 안전한 통신을 시작하기 전에 핸드셰이크 단계가 수행됩니다. SSL/TLS 핸드셰이크 중에 서버는 인증서 형태로 공개 키를 클라이언트에 전달합니다. 인증서에는 서버의 ID, URL, 서버의 공개 키 및 인증서를 검증하는 디지털 서명이 포함됩니다. 클라이언트는 인증서의 유효성을 검사하고 인증서가 신뢰할 수 있는지 결정합니다. 인증서가 신뢰할 수 있는 경우 클라이언트는 SSL/TLS 연결에 사용할 대칭 키를 생성하고 서버의 공개 키를 사용하여 암호화한 다음 서버로 다시 전송합니다. 서버는 개인 키를 사용하여 대칭 키를 해독합니다. 이 연결을 통해 두 시스템 간의 추가 통신은 대칭 키를 사용하여 암호화됩니다.

자체 서명 인증서와 권한 서명 인증서의 두 가지 종류의 인증서가 있습니다. 자체 서명된 인증서는 개인 키를 사용하여 서명합니다. 해당 서명은 신뢰 체인에 연결되어 있지 않기 때문에 확인되지 않습니다. 기관 서명 인증서는 인증 기관, CA가 당사자에게 발급하고 해당 CA(예: VeriSign, CAcert 또는 RSA)에서 서명한 인증서입니다. CA는 인증서 소유자의 신뢰성을 확인합니다.

자체 서명된 인증서는 보다 빠르고 쉽게 생성하고 관리할 수 있는 인프라를 필요로 하지만 타사가 인증을 확인하지 않았기 때문에 클라이언트가 신뢰성을 확인하기 어려울 수 있습니다. 이렇게 하면 본질적으로 자체 서명된 인증서의 보안이 떨어집니다. 권한 서명된 인증서는 설정하는 데 더 많은 노력이 필요할 수 있지만 클라이언트가 인증을 쉽게 확인할 수 있습니다. 제3자가 인증 보유자의 신뢰성을 확인했기 때문에 신뢰도 체인이 만들어집니다.

주의

Red Hat은 영향을 받는 모든 패키지에서 TLSv1.1 또는 TLSv1.2를 기반으로 SSLv2, SSLv3 및 TLSv1.0을 명시적으로 비활성화하는 것이 좋습니다.