💡 웹사이트와 사용자 사이의 통신을 암호화하는 보안 프로토콜 SSL/TLS 는 개인 정보와 민감한 데이터를 안전하게 전송하기 위해 사용합니다.
SSL/TLS?
SSL(Secure Sockets Layer)은 웹 통신의 보안을 위해 사용되는 프로토콜로, 1996년에 SSL 3.0이 발표된 이후 업데이트되지 않았습니다.
SSL은 알려진 여러 취약점이 있으며, 이로 인해 보안 전문가들은 SSL의 사용을 중단하고 TLS(Transport Layer Security)로 전환할 것을 권장하고 있습니다.
🛑 SSL이 취약한 공격
- POODLE (Padding Oracle On Downgraded Legacy Encryption) 공격: SSL 3.0의 취약점을 이용한 공격으로, 암호화된 통신을 해독할 수 있습니다.
- DROWN (Decrypting RSA with Obsolete and Weakened eNcryption) 공격: SSLv2의 취약점을 이용한 공격으로, TLS 암호화를 우회하여 통신 내용을 해독할 수 있습니다.
- BEAST (Browser Exploit Against SSL/TLS) 공격: SSL/TLS의 취약점을 이용한 공격으로, 암호화된 쿠키를 탈취할 수 있습니다.
TLS는 SSL의 후속 버전으로, SSL의 취약점을 개선한 최신 암호화 프로토콜입니다.
TLS는 SSL과 유사한 방식으로 작동하지만, 보안이 강화된 것이 특징입니다.
현재 SSL을 인증 및 제공하는 업체는 사실상 TLS 암호화를 제공하고 있습니다.
SSL의 최종 버전인 3.0과 TLS의 최초 버전인 1.0의 차이는 크지 않습니다.
이름이 바뀐 것은 SSL을 개발한 Netscape가 업데이트에 참여하지 않게 되어 소유권 변경을 위해서 였다고 알려져 있습니다.
SSL의 동작방식
위 이미지는 GPT 신규기능 GPT + DALL·E 3 를 사용하여 SSL의 동작방식을 그려달라 하여 방금 제작한 이미지
- 클라이언트 헬로(Client Hello): 클라이언트(예: 웹 브라우저)는 서버에 연결을 시도하며, 사용 가능한 암호화 방식(암호화 알고리즘, 세션 키 등) 목록을 전송합니다.
- 서버 헬로(Server Hello): 서버는 클라이언트의 목록 중에서 선택한 암호화 방식을 클라이언트에게 알려주고, 자신의 SSL 인증서를 전송합니다.
- 인증서 검증(Certificate Verification): 클라이언트는 서버의 인증서를 검증합니다. 이는 인증서가 신뢰할 수 있는 인증 기관(Certificate Authority, CA)에 의해 발급되었는지, 유효한지, 그리고 서버의 도메인 이름과 일치하는지 확인하는 과정입니다.
- 키 교환(Key Exchange): 인증서가 유효하다면, 클라이언트는 서버의 공개 키를 사용하여 랜덤 하게 생성한 세션 키(대칭 키)를 암호화하고 서버에게 전송합니다. 서버는 자신의 개인 키로 이를 복호화하여 세션 키를 얻습니다.
- 세션 시작(Session Initiation): 서버는 세션 키를 사용하여 암호화된 메시지를 클라이언트에게 전송하여 세션 키가 성공적으로 교환되었음을 확인합니다.
- 암호화된 세션(Encrypted Session): 클라이언트와 서버는 이제 세션 키를 사용하여 데이터를 암호화하고 복호화하며, 이를 통해 안전한 통신 채널을 유지합니다.
SSL/TLS 인증서 유료와 무료의 차이?
- 보증 과 보험
- 유료의 경우 보증과 보험을 제공합니다. 인증서 발급자(Certificate Authority, CA)의 실수로 인한 손실에 대해 일정 금액을 보상받을 수 있음을 의미합니다.
- 유효 기간
- 유료의 경우 1~2년의 유효기간을 가지고 무료의 경우 90일을 가지고 있어 좀 더 잦은 갱신이 필요함
- 인증서 유형
- 유료 인증서는 다양한 유형을 제공합니다. 예를 들어, 확장 검증(EV) 인증서는 조직의 신원을 철저히 검증하며, 브라우저 주소창에 조직의 이름을 표시합니다. 무료 인증서는 주로 도메인 검증(DV) 인증서만을 제공하며, 조직의 신원을 검증하지 않습니다.
- 이 인증서는 웹사이트가 속한 회사나 조직이 실제로 존재하고, 법적으로 인정받는 업체인지를 철저히 검증합니다.
- 검증 과정은 꽤 까다롭고, 여러 법적 문서를 검토해야 합니다.
- 검증이 완료되면, 웹 브라우저의 주소창에 회사나 조직의 이름이 녹색으로 표시되어, 방문자들에게 해당 사이트가 매우 안전하다는 것을 알려줍니다.
- 예를 들어, 은행이나 대형 온라인 쇼핑몰에서 주로 사용합니다.
- 이 인증서는 웹사이트의 도메인 이름(예: [www.example.com)이](http://www.example.㯘%29-ub50a/) 신청자에 의해 통제되고 관리되고 있음만을 확인합니다.
- 검증 과정은 간단하며, 이메일이나 도메인 레코드를 통해 신속하게 이루어집니다.
- 웹 브라우저의 주소창에는 특별한 표시가 없지만, 'https://'와 자물쇠 아이콘이 보여서 방문자들에게 암호화된 연결이라는 것을 알려줍니다.
- 예를 들어, 개인 블로그나 소규모 웹사이트에서 주로 사용합니다.
그러면 무료와 유료를 선택하는 기준이 뭐가있을까?
기업의 신뢰도
민감한 개인정보 ( 카드번호, 카드비밀번호, 여권, 주민등록번호 … )
규정 준수
최근 동향
TLS는 현재 1.0, 1.1, 1.2, 1.3(최신)으로 총 4 개 버전이 존재
이 중 구버전인 1.0 , 1.1 버전은 SSL 3.0과 똑같이 취약한 공격(POODLE과 BEAST와 같은 여러 공격)이 있습니다.
웹 브라우저 제공업체를 시작으로 많은 인터넷 서비스 제공 업체들이 구버전인 1.0 1.1의 지원을 중단하고, 최신버전의 TLS를 사용하도록 권장하고 있습니다.
Mixed contents Error
Mixed contents Error는 웹페이지에 SSL로 암호화된 내용과 암호화되지 않은 내용이 혼합되어 있을 때 발생합니다.
예시
💡 Front Server = HTTPS WAS = HTTP Front Server → WAS 요청을 보냄
위 예시에서는 Front Server에서 Request 한 정보는 SSL로 암호화되어있는 상태, WAS의 Response 정보는 암호화가 되어있지 않은 상태로 Mixed contents Error 가 발생합니다.
⚠️Mixed contents Error를 해결하려면?⚠️
근본적 문제를 해결하기 위해 Front Server와 WAS 모두 SSL/TLS를 발급받아서 서버에 설정해줘야 합니다.
간단한 해결 방법
- 요청이 HTTP이고 WAS가 HTTPS 일 때 발생한 경우 How to fix "insecure content was loaded over HTTPS, but requested an insecure resource"
- <meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests"> 태그를 HTML 파일의 **<head>**에 추가하면, 브라우저는 페이지 내의 모든 HTTP 리소스 요청을 HTTPS로 자동 업그레이드하여 요청하게 됩니다
- WAS 가 HTTP이고 요청이 HTTPS 일 때
- 서버에서 SSL 설정해야 합니다.(근본적으로 해결하세요 👍)
- 외부 리소스를 사용할 때에도 SSL을 사용하도록 하고, 암호화된 연결을 제공하는 호스팅 서비스나 CDN(Content Delivery Network)를 사용합니다.
- CDN?
- CDN(Content Delivery Network)은 전 세계에 분산된 서버 네트워크로, 웹사이트의 콘텐츠를 사용자에게 빠르게 전달하는 서비스입니다. 사용자가 웹사이트에 접속하면, CDN은 사용자에게 가장 가까운 서버에서 콘텐츠를 제공하여, 로딩 시간을 줄이고 사용자 경험을 향상합니다.