💻 SSL / TLS

💡 SSL/TLS

• SSL : Secure Socket Layer
• TLS : Transport Layer Security
• 서버와 클라이언트간 안전한 데이터 전송을 위한 암호화 프로토콜
• SSL 인증서를 통해 안전한 데이터 통신이 가능
• 데이터를 암호화해서 전송하기 위해 대칭키 암호화 방식과 공개키 암호화 방식을 혼합해서 사용

📌 SSL 인증서

• 클라이언트가 접속한 서버가 신뢰 할 수 있는 서버임을 보장
• 안전한 데이터 전송을 위한 데이터 암호화, 복호화 목적의 공개키를 클라이언트에게 제공

✔️ 인증서

• 클라이언트와 서버 간 통신의 신뢰를 보증해주는 문서
• 클라이언트가 서버에 접속하게 되면 서버는 클라이언트에게 이 인증서를 전달해서 신뢰를 얻게 됨
• 인증서 종류
  • DV(Domain Validation)
    • 도메인 소유/관리에 대한 검사인 DCV검사만 확인 후 발급되는 인증서
    • 가격이 저렴하고 CA에서 규정한 Email/DNS/HTTP 인증 방법만 통과하면 발급 완료. 소요시간은 2~5분
  • OV(Organization Validation)
    • 도메인 소유/관리 권한 DCV 검사 뿐만 아니라 해당 인증서를 신청한 기관에 대한 실체 여부까지 확인후 발급되는 인증서
    • 해당 기관 담당자의 재직증명도 필요하고 DV에 비해 가격도 더 비싸다
  • EV(Extended Validation)
    • 가장 높은 인증수준. DV와 OV의 과정을 모두 거치고 추가적으로 사업자 등록증으로 도메인 소유주와 사업자 등록증 상의 업체가 일치하는지 확인하고 전화통화도 해야함
    • 금융사이트 및 관공서에서 사용됨
• 인증서 발급기관
  • CA(Certification Authority)
    • 디지털 인증서를 발급하는 기관
    • 공개키 기반 구조
  • RA(Registration Authority)
    • 디지털 인증서에 관한 사용자 요청을 검증하여 CA가 그것을 발급하도록 알려주는 네트워크 상의 기관
    • 사용자들이 정보를 보다 안전하게 교환할 수 있는 시스템인 공개키 기반구조의 일부. 디지털 인증서는 전자서명과 메시지의 암,복호화에 사용되는 공개키를 담고있음
  • VA(Validation Authority)
    • 디지털 인증서 유효성을 검증

📌 HTTPS 에서 SSL을 이용한 안전한 통신 과정

• SSL Handshake : 실제 데이터를 주고 받기 전 클라이언트와 서버가 탐색하는 과정
  1. 클라이언트가 서버에 접속Client Hello. 이 때 클라이언트가 지원하는 암호화 방식 전송 + 클라이언트 측에서 생성한 랜덤 데이터 전송
  2. 서버가 클라이언트 요청에 응답Server Hello. 이 때 서버가 지원하는 암호화 방식 전송 + 서버측에서 생성한 랜덤 데이터 전송 + 서버의 공개키가 포함된 SSL 인증서 전송
  3. 클라이언트는 서버가 보낸 인증서가 CA(Certificate Authority, 인증기관)에서 발급된 것인지 확인하기 위해 CA 공개키로 인증서를 복호화하여 CA에서 발급되었다는 것을 증명 및 서버 신뢰 + 클라이언트측에서 생성한 랜덤 데이터와 서버측에서 생성한 랜덤데이터를 조합해서 Pre-Master Key(나중에 Session Key가 됨)를 생성하여 서버의 공개키로 암호화 후 전송
  4. 서버는 일련의 과정을 거쳐 Pre-Master Key를 Session Key로 변환, 획득 함
  5. Handshake 종료
• Session
  • Session Key로 대칭키 암호화 방식을 이용한 데이터 송, 수신

공개키 암호화 방식이 안전하게 데이터를 전송할 수 있다는 장점이 있지만 부하가 많이 소모된다는 단점이 있기 때문에 실제 데이터는 대칭키 암호화 방식으로 데이터를 주고 받되 대칭키에 사용되는 키는 공개키 암호화 방식으로 만들어서 데이터 노출을 최대한 피한다.

• Session 종료 : 데이터 송, 수신 종료 시 서로에게 SSL종료를 알리고 통신에 사용된 Session Key폐기
  

📌 SSL Offloading

• SSL 인증서 발급을 위해 클라이언트와 서버간 부하 발생
• 서비스를 제공해야하는 서버가 서비스 제공보다 인증에 더 많은 부하를 안게 됨
• 이러한 문제점을 해결하기 위해 Reverse Proxy를 사용하여 SSL인증서 암호화, 복호화를 담당하게 함
  

• 클라이언트와 Reverse Proxy는 HTTPS 통신을 하고 Reverse Proxy와 서버 그룹들은 HTTP 통신을 함
• Reverse Proxy 서버에 SSL 관련 작업을 위임
• SSL Termination
  • 일반적인 SSL 오프로딩의 구현 방법. 클라이언트와 Reverse Proxy는 SSL 연결을 통해 생성된 세션 키를 대칭키 방식으로 암호화를 하여 데이터를 주고 받으며 Reverse Proxy와 서버들의 그룹간에는 복호화된 데이터를 주고 받음
  • Reverse Proxy의 부하를 줄여줌으로 성능 향상
  • Reverse Proxy와 서버 그룹들간에는 보안성이 떨어질 수 있다는 단점 존재
• SSL Bridging
  • Reverse Proxy가 서버 그룹에게 데이터를 전송할 때 한번 더 암호화 과정을 거쳐서 데이터를 전송하는 방법
  • SSL Termination의 보안 취약점을 개선할 수 있으나 Reverse Proxy는 암호화 과정을 한번 더 거쳐야 하므로 부하 상승으로 인해 성능이 떨어질 수도 있음

📌 SSL 버전

• SSL 1.0
  • 일반인들에게 공개되지 않았던 버전.
• SSL 2.0
  • 넷스케이프사가 1995년에 발표한 버전.
  • Handshake과정에서 방어책이 없어 피해 가능성이 있었음(보안 취약점)
• SSL 3.0
  • 1996년에 SSL 2.0의 심각한 결함을 해결하고 출시 된 버전.
  • 보안취약점 존재 : POODLE(Padding Oracle On Downgraded Legacy Encryption)

📌 TLS(Transport Layer Security)

• TLS는 역시 SSL과 마찬가지로 웹 서버와 클라이언트 간 통신을 암호화 하는데 사용되는 프로토콜.
• TLS는 SSL 3.0을 기반으로 해서 국제 인터넷 표준화 기구인 IETF가 만든 프로토콜
• SSL 3.0에서 보안성 및 안정성이 향상
• TLS 1.0
  • SSL 3.0의 보안 취약점을 대부분 개선
  • SSL 3.0으로 다운그레이드가 가능하다는 보안취약점 존재
• TLS 1.1
  • 암호 블록 체인 공격에 대한 방어 추가
  • IANA 등록 파라미터 지원 추가
• TLS 1.2
  • 취약한 SHA1 해싱 알고리즘을 사용하지 않고 SHA2를 사용
• TLS 1.3
  • 서버에서 인증서를 암호화하여 전달하도록 개선
  • 강화된 보안(안전하지 않은 암호화 방식 지원X)
  • 최초 연결 시에 암호화 통신을 개시하는 절차를 간소화하여 성능 개선