SSL/TLS

dustjs159·2022년 1월 17일
0

Infra

목록 보기
1/3
post-thumbnail

💻 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)
    • 최초 연결 시에 암호화 통신을 개시하는 절차를 간소화하여 성능 개선

0개의 댓글