SSL (r1)

SSL은 1990년대 초, 당시 넷스케이프 커뮤니케이션스의 엔지니어였던 타이거 타이거슨과 크리스토퍼 M. 알렌에 의해 처음 개발되었다. 당시 월드 와이드 웹의 급속한 성장과 함께 온라인 상의 통신, 특히 전자 상거래에서의 데이터 보호 필요성이 대두되면서, 안전한 통신 채널을 제공할 프로토콜의 필요성이 제기되었다. 이에 대한 응답으로 1994년에 SSL 1.0이 내부적으로 설계되었으나, 심각한 보안 결함으로 인해 공개적으로 발표되지는 않았다.

공식적으로 발표된 첫 번째 버전은 1995년 2월에 공개된 SSL 2.0이다. 이 프로토콜은 클라이언트와 서버 간의 기밀성과 무결성을 제공하는 것을 목표로 했다. 그러나 SSL 2.0 역시 여러 보안 취약점을 가지고 있었는데, 특히 MAC(메시지 인증 코드)의 부재와 취약한 암호화 스위트 지원, 그리고 다운그레이드 공격에 취약한 구조가 주요 문제점으로 지적되었다.

이러한 결함을 해결하기 위해 넷스케이프는 같은 해인 1995년에 SSL 3.0을 발표했다. SSL 3.0은 이전 버전의 보안 문제를 상당 부분 해결한 획기적인 업데이트였다. 주요 개선 사항은 다음과 같다.

SSL 3.0은 이후 거의 20년 동안 인터넷 보안의 초석으로 자리 잡았으며, TLS 1.0의 기반이 되었다. 그러나 2014년에 발표된 POODLE 취약점으로 인해 SSL 3.0의 사용이 공식적으로 권고되지 않게 되었다.

SSL 3.0은 여러 보안 취약점이 발견되면서 한계에 부딪혔다. 특히 2014년에는 POODLE 공격[2]이 발견되어 SSL 3.0의 설계 결함이 드러났다. 이 공격은 암호화 방식의 취약점을 이용해 통신을 해독할 수 있었으며, 결국 SSL 3.0의 사용 중단을 촉발하는 결정적 계기가 되었다.

이러한 문제를 해결하기 위해 IETF(국제 인터넷 표준화 기구)는 SSL 프로토콜을 표준화하여 새로운 이름으로 발전시켰다. 1999년에 발표된 TLS 1.0은 SSL 3.0을 기반으로 했지만, 암호화 알고리즘과 핸드셰이크 과정에서 보안성을 강화했다. 이후 TLS는 지속적으로 개선되어 TLS 1.1, TLS 1.2, TLS 1.3 버전이 등장했다.

현대의 보안 표준은 SSL이 아닌 TLS를 지향한다. 주요 브라우저와 웹 서버는 오래된 SSL 버전의 지원을 중단했으며, 업계에서는 TLS 1.2 또는 TLS 1.3의 사용을 권장한다. 그러나 역사적 관습과 인지도 때문에 'SSL'이라는 용어는 여전히 TLS 기술과 인증서를 포ꭉ적으로 지칭하는 데 널리 사용된다.

클라이언트 헬로는 SSL/TLS 핸드셰이크 과정의 첫 번째 단계이다. 클라이언트(일반적으로 웹 브라우저)가 서버에 접속을 시도할 때, 보안 연결을 수립하기 위해 필요한 초기 정보를 담은 메시지를 서버로 전송한다.

이 메시지에는 클라이언트가 지원하는 TLS 프로토콜의 최고 버전, 사용 가능한 암호 스위트 목록, 그리고 무작위로 생성된 데이터인 '클라이언트 랜덤'이 포함된다. 암호 스위트는 이후 통신에 사용될 대칭키 암호화 알고리즘, 키 교환 방식, 메시지 인증 코드 알고리즘 등의 조합을 정의한다. 또한, 필요한 경우 서버 이름 표시 확장을 포함하여 특정 호스트명에 연결하려는 의도를 명시하기도 한다[4].

클라이언트 헬로의 목적은 서버와의 호환성을 탐색하고, 이후 모든 보안 파라미터의 기초가 될 공유 비밀을 생성하는 데 필요한 초기 재료를 제공하는 것이다. 서버는 이 메시지를 받아 클라이언트가 제안한 항목들 중 자신도 지원하는 가장 강력한 프로토콜 버전과 암호 스위트를 선택하여 응답하게 된다.

서버는 클라이언트의 헬로 메시지를 받은 후, 자신의 디지털 인증서를 포함한 서버 헬로 메시지로 응답합니다. 이 인증서는 서버의 공개키와 신원 정보(예: 도메인 이름)를 포함하며, 신뢰할 수 있는 인증 기관에 의해 서명되어 있습니다. 서버는 또한 지원하는 암호 스위트 목록 중에서 클라이언트가 제안한 것과 호환되는 가장 강력한 암호 스위트를 선택하여 알립니다.

서버의 디지털 인증서는 핸드셰이크의 핵심 요소입니다. 클라이언트(일반적으로 웹 브라우저)는 이 인증서를 받아 다음과 같은 검증 과정을 거칩니다.

1. 인증서의 유효 기간을 확인합니다.

2. 인증서에 명시된 도메인 이름이 실제 접속하려는 서버의 도메인과 일치하는지 확인합니다.

3. 인증서의 발급자(인증 기관)가 클라이언트의 신뢰할 수 있는 루트 인증서 저장소에 있는지 확인하고, 인증서 체인을 따라 루트 인증서까지 검증하여 서명의 유효성을 확인합니다[5].

이 검증이 성공하면, 클라이언트는 서버의 신원을 신뢰하고 해당 인증서에 포함된 서버의 공개키를 안전하게 사용할 수 있게 됩니다. 서버는 필요에 따라 클라이언트 인증서를 요청할 수도 있지만, 일반적인 웹 사이트 접속에서는 생략되는 경우가 많습니다.

SSL/TLS 핸드셰이크 과정에서 서버의 디지털 인증서가 검증되면, 클라이언트와 서버는 실제 데이터를 암호화하는 데 사용할 대칭키를 안전하게 공유하는 단계로 진행한다. 이 과정을 키 교환이라고 한다.

가장 일반적인 키 교환 방식은 RSA 암호화를 이용하는 방법이다. 클라이언트는 무작위로 생성한 프리마스터 시크릿이라는 데이터를 서버의 공개키로 암호화하여 서버에 전송한다. 서버는 자신만이 가지고 있는 개인키로 이 암호문을 복호화하여 프리마스터 시크릿을 얻는다. 이렇게 양측이 공유한 프리마스터 시크릿과 핸드셰이크 과정에서 교환한 난수들을 특정 알고리즘에 입력하여, 최종적인 대칭키를 각자 독립적으로 생성한다. 이 키는 세션 키라고도 불린다.

또 다른 현대적인 키 교환 방식으로는 디피-헬만 키 교환을 변형한 ECDHE가 널리 사용된다. 이 방식은 서버의 개인키로 서명된 매개변수를 교환하여, 각자가 독립적으로 계산을 통해 공유 비밀값을 도출한다. ECDHE의 주요 장점은 전방향 비밀성을 제공한다는 점이다. 이는 향후 서버의 개인키가 유출되더라도 과거에 교환된 세션 키를 복호화할 수 없음을 의미한다[6].

키 교환이 완료되면, 클라이언트와 서버는 핸드셰이크의 모든 메시지에 대한 무결성을 검증하기 위해 핸드셰이크 완료 메시지를 교환한다. 이 메시지는 방금 합의된 암호 스위트와 세션 키로 암호화되어 전송된다. 이후부터는 모든 애플리케이션 데이터(예: HTTP 요청과 응답)가 이 세션 키를 사용한 대칭키 암호화 방식으로 안전하게 전송된다.

대칭키 암호화는 암호화와 복호화에 동일한 비밀 키를 사용하는 암호화 방식이다. 이 키는 통신을 주고받는 당사자들만 공유하며, 외부에 노출되어서는 안 된다. 대칭키 암호화는 공개키 암호화에 비해 계산 부하가 적고 속도가 매우 빠르다는 장점이 있어, 대량의 데이터를 실시간으로 암호화하는 데 적합하다.

SSL/TLS 프로토콜에서는 핸드셰이크 과정에서 협상된 이 대칭키를 '세션 키'라고 부른다. 이 세션 키는 핸드셰이크가 완료된 후 실제 애플리케이션 데이터를 암호화하는 데 사용된다. 일반적으로 사용되는 대칭키 암호화 알고리즘으로는 AES(Advanced Encryption Standard), 3DES, ChaCha20 등이 있다.

대칭키 암호화의 가장 큰 과제는 키를 안전하게 교환하고 관리하는 것이다. 통신 시작 전에 키를 공유하는 방법이 필요하며, 키가 유출되면 암호화된 모든 통신이 위험에 처하게 된다. SSL/TLS는 이 문제를 해결하기 위해 공개키 암호화를 이용해 대칭키를 안전하게 교환한 후, 실제 데이터 전송에는 효율적인 대칭키 암호화를 사용하는 하이브리드 방식을 채택한다.

공개키 암호화는 대칭키 암호화와 달리, 암호화와 복호화에 서로 다른 두 개의 키를 사용하는 비대칭 암호화 방식을 가리킨다. 이 두 키는 공개키와 개인키로 구성되며, 수학적으로 밀접하게 연관되어 있지만 한 쪽 키로부터 다른 쪽 키를 추론하는 것은 현실적으로 불가능하다[7]. 공개키는 누구에게나 공개되어 암호화에 사용되며, 개인키는 소유자만이 비밀로 보관하여 복호화에 사용한다.

SSL/TLS에서 공개키 암호화는 핵심적인 두 가지 역할을 수행한다. 첫째, 핸드셰이크 과정 초기에 대칭키를 안전하게 교환하는 데 사용된다. 클라이언트는 서버의 공개키로 대칭 세션 키를 암호화하여 전송하면, 오직 해당 개인키를 가진 서버만이 이를 복호화할 수 있다. 둘째, 디지털 인증서의 검증과 전자 서명에 활용된다. 인증서는 인증 기관(CA)의 개인키로 서명되어 있으며, 클라이언트는 CA의 공개키를 이용해 그 서명을 검증함으로써 인증서의 진위와 무결성을 확인한다.

공개키 암호화 알고리즘의 대표적인 예로는 RSA, 디피-헬먼 키 교환(DH), 타원곡선 암호(ECC) 등이 있다. 이들 알고리즘은 보안 강도와 계산 효율성 측면에서 차이를 보인다.

공개키 암호화는 높은 수준의 보안을 제공하지만, 순수 대칭키 암호화에 비해 계산 부하가 크다는 단점이 있다. 따라서 SSL/TLS는 실제 데이터 암호화에는 효율적인 대칭키 방식을 사용하고, 초기 보안 채널 수립과 인증 과정에서만 공개키 방식을 적용하는 하이브리드 방식을 채택한다.

디지털 인증서는 공개키 암호화 시스템에서 통신 상대방의 신원을 확인하고 그 공개키의 소유권을 보증하는 전자 문서이다. 이 인증서는 X.509라는 표준 형식을 따르며, 주체(인증서 소유자)의 정보, 주체의 공개키, 인증서를 발급한 인증 기관(CA)의 디지털 서명, 유효 기간 등을 포함한다. SSL/TLS 핸드셰이크 과정에서 서버는 클라이언트에게 이 인증서를 전송하여 자신의 신원을 증명한다.

인증 기관(CA)은 디지털 인증서를 발급하고 관리하는 신뢰할 수 있는 제3자 기관이다. CA의 핵심 역할은 인증서 신청자의 신원을 검증한 후, 자신의 비밀키로 해당 인증서에 디지털 서명을 하는 것이다. 클라이언트(예: 웹 브라우저)는 미리 내장된 '신뢰할 수 있는 루트 인증서 저장소'를 가지고 있으며, 이 저장소에는 주요 CA들의 공개키(루트 인증서)가 포함되어 있다. 서버로부터 받은 인증서의 서명 체인을 이 루트 CA까지 거슬러 올라가 검증함으로써 인증서의 진위를 확인할 수 있다.

인증서의 신뢰 체계는 다음과 같은 계층 구조로 이루어진다.

인증서의 유효성은 유효 기간과 폐기 상태에 의해서도 결정된다. 인증서는 발급 시점과 만료 시점을 명시하며, 이 기간을 벗어나면 무효가 된다. 또한, 만료 전이라도 개인키 유출 등의 사유로 인증서를 더 이상 사용해서는 안 될 경우, 발급 CA는 해당 인증서를 인증서 폐지 목록(CRL)에 등록하거나 온라인 인증서 상태 프로토콜(OCSP)을 통해 폐기 상태를 알린다. 클라이언트는 이 정보를 확인하여 폐기된 인증서를 거부할 수 있다.

도메인 검증(DV) 인증서는 가장 기본적인 수준의 SSL 인증서이다. 이 인증서의 발급 목적은 특정 도메인 이름의 소유권을 확인하는 데 있다. 발급 기관(CA)은 신청자가 해당 도메인의 관리 권한을 가지고 있는지 여부만을 검증하며, 조직의 실체나 법적 존재 여부는 확인하지 않는다.

검증 과정은 일반적으로 이메일을 통해 이루어진다. CA는 도메인의 WHOIS 정보에 등록된 관리자 이메일 주소나, admin@, webmaster@와 같은 사전 정의된 주소로 확인 이메일을 발송한다. 신청자가 이 이메일에 포함된 링크를 클릭하거나 인증 코드를 확인함으로써 도메인에 대한 통제권을 증명하면 검증이 완료된다. 일부 CA는 DNS 레코드에 특정 TXT 값을 추가하는 방식으로도 검증을 수행한다.

DV 인증서는 주로 개인 블로그, 소규모 웹사이트, 또는 테스트 환경에서 널리 사용된다. 또한 Let's Encrypt와 같은 무료 CA의 등장으로 보편화되었다. 이 인증서는 통신 채널의 기밀성과 데이터 무결성을 제공하지만, 웹사이트를 운영하는 조직의 신원에 대한 정보는 제공하지 않는다는 점이 한계로 지적된다.

조직 검증 인증서는 도메인 검증(DV) 인증서보다 한 단계 높은 수준의 검증을 거쳐 발급되는 디지털 인증서이다. 이 인증서를 발급받기 위해서는 신청 조직이 해당 도메인 이름에 대한 소유권뿐만 아니라, 법적으로 실재하는 합법적인 사업체 또는 조직인지에 대한 검증 절차를 통과해야 한다. 인증 기관은 사업자 등록증, 법인 등기부 등본, 전화번호 검증 등을 통해 조직의 실체와 도메인 소유권을 확인한다.

발급 과정에서 조직의 실제 정보가 검증되므로, 인증서 내부에는 조직의 공식 명칭이 포함된다. 이는 사용자가 SSL/TLS 핸드셰이크 과정 중에 서버로부터 받은 인증서 세부 정보를 확인할 때, 해당 웹사이트를 운영하는 실체 있는 조직의 이름을 확인할 수 있음을 의미한다. 이는 피싱 사이트와 같은 불법 사이트가 동일한 도메인 이름을 가진 합법적인 조직을 사칭하는 것을 어느 정도 방지하는 데 기여한다.

OV 인증서는 주로 기업의 공식 웹사이트, 회사 포털, 또는 고객 데이터를 다루지만 금융 거래와 같은 최고 수준의 검증이 필수적이지는 않은 비즈니스 사이트에 사용된다. DV 인증서보다 높은 신뢰도를 제공하지만, 브라우저 주소창에 조직 이름을 직접 표시해주는 확장 검증(EV) 인증서만큼 눈에 띄는 시각적 신호는 제공하지 않는다. 최근에는 많은 웹 브라우저가 UI를 단순화하면서 EV 인증서의 시각적 차별화를 줄였기 때문에, OV 인증서는 비용 대비 효과적인 조직 신원 보증 수단으로 여겨지기도 한다.

확장 검증 인증서는 SSL 인증서 중에서 발급 절차가 가장 엄격하고, 신원 확인 수준이 가장 높은 인증서 유형이다. 이 인증서를 발급받기 위해서는 인증 기관이 법인 등기부 등본, 실제 영업장소 확인, 신청 담당자 직위 확인 등 조직의 실체와 법적 존재를 철저히 검증한다. 이러한 까다로운 검증 과정 때문에 발급에 일반적으로 며칠에서 일주일 이상의 시간이 소요된다.

웹 브라우저에서 확장 검증 인증서가 사용된 사이트를 접속하면, 주소창에 조직의 법적 명칭이 녹색으로 표시되고, 경우에 따라 인증 기관의 이름도 함께 나타난다. 이는 사용자에게 해당 웹사이트가 합법적인 조직에 의해 운영되고 있음을 시각적으로 강력하게 알리는 역할을 한다. 특히 금융 기관, 전자 상거래 사이트, 정부 포털과 같이 높은 신뢰가 요구되는 서비스에서 널리 채택되었다.

그러나 확장 검증 인증서의 유용성에 대한 논쟁이 지속되어 왔다. 일부 연구에 따르면 일반 사용자 대부분이 주소창의 녹색 표시를 주의 깊게 확인하지 않는다는 지적이 제기되었다[8]. 또한, 2018년 이후 구글 크롬, 애플 사파리, 모질라 파이어폭스 등 주요 웹 브라우저들이 보안 UI를 단순화하는 과정에서 주소창 내 녹색 조직명 표시를 단계적으로 제거하기 시작했다. 이로 인해 확장 검증 인증서의 시각적 차별화 효과는 크게 약화되었다.

현재 확장 검증 인증서는 여전히 가장 높은 수준의 조직 검증을 제공하지만, 기술적인 암호화 강도는 다른 유형의 인증서와 동일하다. 따라서 높은 신뢰성을 상징적으로 보여주어야 하는 기업이나 기관에서는 여전히 가치를 인정받고 있으나, 많은 웹사이트 운영자들은 비용과 발급 시간이 더 적게 드는 조직 검증 인증서나 도메인 검증 인증서를 선택하는 추세이다.

SSL과 그 후속 프로토콜인 TLS의 핵심 보안 기능 중 하나는 기밀성을 보장하는 것이다. 이는 통신 중인 두 당사자 사이에 오가는 데이터가 제3자에게 노출되지 않도록 하는 것을 의미한다. 네트워크를 통해 전송되는 데이터는 패킷 스니핑과 같은 방법으로 쉽게 가로챌 수 있기 때문에, 기밀성은 민감한 정보를 다루는 모든 온라인 상호작용의 필수 조건이다.

기밀성은 대칭키 암호화 방식을 통해 실현된다. SSL 핸드셰이크 과정에서 클라이언트와 서버는 안전하게 세션 키를 협상한다. 이 세션 키는 해당 통신 세션 동안만 사용되는 일회성 대칭키이다. 핸드셰이크가 완료되면, 이후 모든 애플리케이션 데이터는 이 세션 키를 사용해 암호화된 후 전송된다. 수신 측은 동일한 키로 데이터를 복호화하여 원본 메시지를 확인한다. 대칭키 암호화는 AES나 ChaCha20와 같은 강력한 알고리즘을 사용하며, 처리 속도가 빠르기 때문에 실시간 데이터 암호화에 적합하다.

결과적으로, 중간에서 통신을 가로채는 공격자는 암호화된 패킷을 획득하더라도 세션 키를 알지 못하면 원본 데이터를 알아낼 수 없다. 이는 온라인 뱅킹, 이메일, 메신저 대화, 개인정보 제출 등 모든 민감한 데이터 교환의 안전한 토대를 마련한다.

SSL/TLS의 무결성 검증 기능은 전송 중인 데이터가 암호화된 채널을 통해 도중에 변조되거나 손상되지 않았음을 보장하는 역할을 한다. 이는 암호학적 해시 함수와 메시지 인증 코드(MAC)를 결합한 메커니즘을 통해 달성된다.

핵심 과정은 다음과 같다. 통신 세션이 수립되면, 협상된 대칭키 암호화 키와 함께 특정 해시 알고리즘(예: HMAC-SHA256)이 사용된다. 송신 측은 전송할 평문 데이터에 대해 MAC 알고리즘을 적용하여 고정 길이의 MAC 태그를 생성한다. 이 태그는 데이터와 비밀 키에 종속적이므로, 데이터가 단일 비트라도 변경되면 전혀 다른 태그 값이 계산된다. 이후 평문 데이터와 MAC 태그가 함께 암호화되어 수신자에게 전송된다.

수신 측은 암호문을 복호화한 후, 동일한 비밀 키와 알고리즘을 사용하여 수신된 평문 데이터로부터 MAC 태그를 다시 계산한다. 이렇게 새로 계산된 태그 값과 전송받은 태그 값을 비교하여 일치 여부를 확인한다. 두 값이 일치하면 데이터가 전송 중 변조되지 않았음을, 일치하지 않으면 데이터가 손상되었거나 중간에 조작 시도가 있었음을 의미한다. 이 검증 실패 시 SSL/TLS 프로토콜은 연결을 즉시 종료하여 손상된 데이터의 사용을 방지한다.

이 무결성 보호는 기밀성 보장과 별개이지만 상호 보완적인 보안 목표를 이룬다. 공격자가 암호문을 가로채 내용을 알 수는 없더라도 비트를 무작위로 변경하는 경우에도 무결성 검증이 이를 탐지할 수 있다[10]. 따라서 SSL/TLS는 기밀성, 무결성, 인증이라는 세 가지 핵심 보안 서비스를 통합적으로 제공한다.

SSL과 그 후속 프로토콜인 TLS의 핵심 보안 기능 중 하나는 통신 상대방의 신원을 확인하는 신원 인증이다. 이 기능은 클라이언트가 연결하려는 서버가 실제로 해당 도메인의 합법적인 소유자임을 보장하여, 중간자 공격을 방지하는 데 결정적인 역할을 한다.

신원 인증은 주로 디지털 인증서 체계를 통해 이루어진다. 서버는 신뢰할 수 있는 제3자인 인증 기관으로부터 자신의 공개키와 신원 정보가 포함된 인증서를 발급받는다. 클라이언트는 서버로부터 전달받은 이 인증서의 유효성을 검증한다. 검증 과정에는 인증서의 서명을 발급한 CA가 클라이언트의 신뢰 저장소에 등록된 신뢰할 수 있는 기관인지 확인하고, 인증서가 만료되지 않았으며, 연결하려는 도메인 이름과 인증서 내의 도메인 이름이 일치하는지 점검하는 것이 포함된다.

인증서의 종류에 따라 검증 수준은 달라진다. DV 인증서는 단순히 도메인 소유권만을 확인하는 반면, OV 인증서와 EV 인증서는 도메인 소유 조직의 실체에 대한 추가적인 법적 검증을 수행한다. 특히 EV 인증서는 웹 브라우저의 주소창에 조직 이름을 표시하여 사용자에게 더 높은 수준의 신원 보증을 제공한다. 이와 같은 인증 과정을 통해 사용자는 자신의 민감한 정보를 전송하기 전에 상대방 서버의 정체성을 신뢰할 수 있게 된다.

웹 서버에 SSL/TLS를 구현하려면 서버 소프트웨어에 적절한 설정을 구성하고 유효한 디지털 인증서를 설치해야 한다. 일반적인 과정은 인증서 파일과 개인 키 파일을 서버의 지정된 디렉토리에 업로드한 후, 서버 설정 파일에서 이 파일들의 경로와 사용할 암호화 프로토콜, 암호 스위트 등을 명시하는 것이다. 널리 사용되는 아파치 HTTP 서버의 경우 httpd.conf 또는 가상 호스트 설정 파일 내 SSLCertificateFile 및 SSLCertificateKeyFile 지시어를 통해 인증서와 키를 지정한다. Nginx에서는 ssl_certificate와 ssl_certificate_key 지시어를 사용하여 비슷한 설정을 수행한다.

서버 설정 시 중요한 보안 요소는 지원할 SSL/TLS 프로토콜 버전과 암호 스위트를 제한하는 것이다. 오래되고 안전하지 않은 SSL 2.0, 3.0 및 TLS 1.0은 사용하지 않도록 비활성화하는 것이 표준 관행이다. 현재는 TLS 1.2 또는 1.3을 기본으로 설정한다. 또한 강력한 암호화 알고리즘을 우선시하는 암호 스위트 목록을 구성해야 한다. 설정이 완료되면 nginx -t(Nginx)나 apachectl configtest(Apache)와 같은 명령어로 구문 오류를 검증한 후 서비스를 재시작하여 적용한다.

자동화와 편의성을 높이기 위해 Let's Encrypt와 같은 무료 인증서 발급 기관의 도구를 활용하는 경우가 많다. Certbot은 대표적인 클라이언트 소프트웨어로, 인증서 발급, 설치, 갱신 과정을 자동으로 처리해준다. 이는 특히 인증서 만료로 인한 서비스 중단 위험을 줄이는 데 유용하다. 설정의 정확성과 보안 강도는 온라인 검사 도구(예: SSL Labs의 SSL Server Test)를 통해 확인할 수 있다.

인증서 발급은 신뢰할 수 있는 인증 기관을 통해 이루어진다. 발급 절차는 선택한 인증서 유형(도메인 검증(DV) 인증서, 조직 검증(OV) 인증서, 확장 검증(EV) 인증서)에 따라 검증 수준과 소요 시간이 달라진다. 일반적인 절차는 다음과 같다. 먼저, 서버 관리자는 인증 기관 웹사이트에서 인증서 신청을 하고, 서버에서 개인키와 함께 인증서 서명 요청 파일을 생성하여 제출한다. 그 후, 인증 기관은 요청된 도메인의 소유권 또는 조직 정보를 해당 인증서 수준에 맞게 검증하고, 검증이 완료되면 서명된 디지털 인증서를 발급한다. 발급된 인증서는 서버에 설치되고, 해당 개인키와 연결되어 SSL/TLS 핸드셰이크 과정에서 사용된다.

발급된 SSL 인증서는 유효 기간을 가지며, 보통 1년에서 최대 13개월[12] 동안 유효하다. 만료되기 전에 갱신 절차를 수행해야 지속적인 서비스가 가능하다. 갱신 절차는 초기 발급과 유사하지만, 기존 검증 정보를 재사용할 수 있어 더 간단한 경우가 많다. 많은 인증 기관과 호스팅 제공업체는 만료 알림 서비스와 자동 갱신 기능을 제공한다.

인증서 관리를 효율적으로 하기 위해 인증서 관리 도구나 중앙 집중식 인증서 관리 시스템을 도입하는 것이 좋다. 이러한 도구는 여러 서버에 분산된 인증서의 유효 기간을 모니터링하고, 갱신 프로세스를 자동화하며, 갱신된 인증서를 배포하는 작업을 간소화한다. 이는 인증서 만료로 인한 서비스 중단 사고를 방지하는 데 핵심적이다.

SSL과 그 후속 프로토콜인 TLS는 수년에 걸쳐 여러 심각한 취약점이 발견되었다. 이러한 취약점들은 프로토콜 설계 결함이나 특정 암호화 방식의 구현 오류에서 비롯되었으며, 대부분의 경우 프로토콜 업데이트나 암호 스위트 비활성화를 통해 해결되었다.

주요 과거 취약점으로는 다음과 같은 것들이 있다.

이러한 취약점들은 보안 프로토콜의 지속적인 진화를 촉진하는 계기가 되었다. 대부분의 공격은 오래된 프로토콜 버전(예: SSL 3.0, TLS 1.0)이나 약한 암호화 알고리즘(예: RC4, MD5)의 사용과 관련이 있었다. 이에 따라 업계는 TLS 1.2 및 TLS 1.3으로의 전환을 가속화했고, 안전하지 않은 암호 스위트를 비활성화하는 모범 사례가 정립되었다. 또한 Heartbleed와 같은 사건은 오픈소스 보안 소프트웨어 유지 관리의 중요성을 전 세계에 각인시켰다.

SSL/TLS는 지속적으로 진화하는 보안 위협에 직면해 있습니다. 현대적인 공격 기법은 프로토콜 자체의 결함보다는 구현상의 문제, 설정 오류, 또는 암호화 강도를 우회하는 방법에 집중하는 경향이 있습니다.

주요 위협 중 하나는 암호 스위트의 안전성 저하입니다. 오래된 암호화 알고리즘(RC4, DES, SHA-1 등)은 컴퓨팅 성능 향상과 새로운 공격 기법(예: 충돌 공격)으로 인해 더 이상 안전하지 않게 되었습니다. 또한 패딩 오라클 공격(POODLE)이나 암호화 프로토콜의 재협상 기능을 악용하는 공격도 지속적으로 발견되었습니다. 현대적인 대응책은 강력한 암호 스위트만을 허용하고, 오래된 프로토콜 버전(SSL 2.0/3.0, TLS 1.0/1.1)을 비활성화하는 것입니다.

또 다른 심각한 위협은 인증서 체계에 대한 공격입니다. 인증 기관(CA)의 사설 키가 유출되거나, 합법적인 CA가 악의적으로 행동할 경우, 공격자는 어떤 사이트로든 위조된 인증서를 발급할 수 있습니다. 인증서 투명성(CT) 로그는 이러한 위협을 완화하기 위해 도입된 기술입니다. 또한, 중간자 공격(MITM)을 수행하는 공공 와이파이 네트워크나 악성 소프트웨어는 사용자의 트래픽을 가로채 암호화 연결을 다운그레이드하거나 정상적인 인증서를 위조된 것으로 대체하려 시도합니다.

이러한 위협에 대응하기 위해 TLS 1.3은 프로토콜을 크게 단순화하고 암호화 기본값을 강화하여 여러 역사적인 취약점을 근본적으로 제거했습니다. 또한, HSTS(HTTP Strict Transport Security)와 같은 메커니즘은 브라우저가 항상 암호화된 연결을 사용하도록 강제하여 다운그레이드 공격을 방지합니다. 결국, 현대적인 SSL/TLS 보안은 강력한 최신 프로토콜 버전 채택, 엄격한 서버 구성, 그리고 인증서 생태계의 투명성 유지에 달려 있습니다.

SSL/TLS의 안전한 구현을 위해서는 최신 프로토콜 버전 사용, 강력한 암호 스위트 구성, 그리고 적절한 인증서 관리를 포함한 모범 사례를 따르는 것이 필수적이다.

현재 표준은 TLS 1.2 또는 TLS 1.3을 사용하는 것이며, SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1과 같은 오래되고 취약한 버전은 완전히 비활성화해야 한다. 서버는 강력한 암호화 알고리즘을 우선시하도록 암호 스위트를 구성해야 한다. 일반적으로 권장되는 설정은 다음과 같다.

인증서 관리 측면에서는 신뢰할 수 있는 인증 기관으로부터 인증서를 발급받고, 만료되기 전에 주기적으로 갱신해야 한다. 인증서 투명성 로그를 활용하여 잘못 발급된 인증서를 탐지할 수 있다. 또한, HTTP Strict Transport Security 헤더를 설정하여 브라우저가 항상 HTTPS를 통해 사이트에 접속하도록 강제하는 것이 중요하다. 이는 SSL 스트리핑 공격을 방지하는 데 도움이 된다.

서버 설정 후에는 SSL Labs와 같은 외부 평가 도구를 이용하여 구성의 보안 수준을 정기적으로 점검하고 검증해야 한다. 이러한 도구는 취약한 프로토콜 버전, 약한 암호 스위트, 잘못된 인증서 체인 등 일반적인 설정 오류를 식별해 준다. 보안 패치가 발표되면 웹 서버 소프트웨어와 암호화 라이브러리를 지체 없이 업데이트하여 알려진 취약점으로부터 시스템을 보호해야 한다.

HTTPS는 HTTP 프로토콜에 SSL 또는 그 후속 프로토콜인 TLS를 적용하여 보안성을 강화한 프로토콜이다. 기본적인 통신 구조는 HTTP와 동일하지만, 모든 데이터가 암호화된 채널을 통해 전송된다는 점이 근본적인 차이점이다. 웹 브라우저의 주소창에 나타나는 자물쇠 아이콘은 해당 연결이 HTTPS를 사용하고 있음을 시각적으로 나타내는 표시이다.

HTTPS 연결은 표준 HTTP 포트인 80번 대신 443번 포트를 사용한다. 연결 수립 과정에서 SSL/TLS 핸드셰이크가 먼저 수행되어 암호화 통신 채널을 설정한 후, 그 안에서 일반 HTTP 요청과 응답이 교환된다. 이는 기밀성 보장, 무결성 검증, 그리고 서버의 신원 인증이라는 세 가지 핵심 보안 목표를 실현한다.

현대 웹에서는 HTTPS의 사용이 필수적인 표준이 되었다. 주요 웹 브라우저들은 HTTPS가 아닌 사이트에 대해 '안전하지 않음' 경고를 표시하며, 검색 엔진 최적화 측면에서도 HTTPS를 사용하는 사이트에 가산점을 부여한다[14]. 이는 중간자 공격, 데이터 도청, 콘텐츠 변조 등 다양한 보안 위협으로부터 사용자를 보호하기 위한 조치이다.

STARTTLS는 SMTP, IMAP, POP3와 같은 일반 텍스트 통신 프로토콜에 TLS 암호화를 적용하기 위한 프로토콜 확장 명령어이다. 이 명령어를 사용하면, 클라이언트와 서버는 기존의 평문 연결을 암호화된 SSL/TLS 연결로 업그레이드한다. 초기 연결은 암호화되지 않은 상태로 시작하여, 서버의 STARTTLS 기능 지원 여부를 확인한 후 보안 채널을 협상한다는 점이 기본적으로 HTTPS와 차별화된다.

주요 적용 분야는 이메일 전송 및 수신 프로토콜이다. 예를 들어, SMTP 포트 25나 587에서 서버는 220 준비 완료 메시지를 보낸 후, 클라이언트가 STARTTLS 명령을 보내면 서버는 220 Ready to start TLS로 응답하며 이후의 모든 통신은 TLS로 암호화된다. 이 방식은 레거시 시스템과의 호환성을 유지하면서 보안을 강화할 수 있는 장점이 있다.

그러나 STARTTLS는 다운그레이드 공격에 취약할 수 있다. 공격자가 중간에서 STARTTLS 명령 자체를 제거하거나 차단하면, 통신 당사자들은 암호화되지 않은 평문 연결을 그대로 사용하게 될 위험이 있다. 이러한 공격을 방지하기 위해 MTA-STS나 DANE 같은 보완 프로토콜이 개발되었다. 또한, 많은 현대 이메일 및 클라이언트 서버는 암호화 연결을 기본으로 요구하거나, 별도의 암호화 전용 포트(IMAPS의 993, POP3S의 995 등)를 우선적으로 사용하는 방향으로 발전하고 있다.