[도커교과서] SSL/TLS 보안 소켓 계층

도커 교과서 

15장 보안 원격 접근 및 CI/CD를 위한 도커 설정

15-2 보안 원격 접근을 위한 도커 엔진 설정

- 도커 교과서 실습에 파일을 기준으로 설명함.


- SSL/TLS의 의미 🔐

    - SSL (Secure Socket Layer) / TLS (Transport Layer Security)

  • SSL은 1990년대 초반에 처음 도입되었음. 

  • 이후 TLS가 SSL의 보안 취약점을 보완하며 등장했음. 

  • SSL은 이제 보안상의 이유로 완전히 폐기되었고, 현재는 TLS 1.2와 TLS 1.3이 널리 사용되고 있음. 

  • 현재는 TLS 1.2가 가장 대중화되어 사용되고 있음. 



- SSL/TLS의 기능 🛠️

  • Data Encryption (데이터 암호화): 데이터를 암호화하여, 제3자가 데이터를 가로채거나 변경할 수 없도록 보호

  • Data Integrity (데이터 무결성): 전송된 데이터가 변경되지 않았음을 보장

  • Authentication (인증): 서버와 클라이언트 간의 신뢰를 구축하고, 상대방이 인증된 주체임을 확인

  •  위의 특징을 이용해 SSL/TLS 인증서는 웹 서버와 클라이언트 간의 데이터를 암호화하고 인증하는 데 사용

  •  이를 통해 사용자는 웹사이트가 진짜 서버인지 확인하고 전송되는 데이터의 안전성을 보장 받을 수 있음



- SSL/TLS의 네트워크 계층 구조 🌐

 OSI 7 Layer 계층 중 Application layer(7)와 Transfer Layer(4) 사이에 존재 

  • TCP를 기반으로 암호화하고 데이터를 전송



- SSL/TLS 암호화 통신 🔑

  • RSA 비대칭키 암호화와 대칭키 방식을 혼합하여 사용함.(하이브리드)

    1. 처음에 RSA 비대칭키 암호화 방식으로 대칭키를 교환

    2. 실제 통신을 할 때는 대칭키 방식을 사용하여 데이터를 빠르게 암호화하고 전송

      • 대칭키 방식은 속도가 빠르고, CPU 리소스 소모가 적음

TLS를 적용하면 자물쇠 모양이 표시(브라우저 공통적) Https 적용

  • HTTPS는 TLS 통신 위에서 암호화를 구현한 것 



- SSL/TLS 핸드셰이크 과정 🤝

TLS 통신의 대략적인 Work flow

- SSL/TLS 핸드셰이크 과정 정리

  1. 클라이언트 → 서버 (ClientHello): 클라이언트가 서버에 암호화 방식 등 정보를 보내면서 연결 시작
    client-key.pem과 client-cert.pem과 ca.pem을 사용해서 안전하게 연결할 준비

  2. 서버 → 클라이언트 (ServerHello): 서버가 클라이언트의 요청에 응답하고, 서버 인증서인 server-cert.pem을 클라이언트에게 전달 서버의 공개 키가 전달됨

    • 클라이언트는 ca.pem을 사용해서 서버의 인증서가 신뢰할 수 있는지 확인

  3. 클라이언트 → 서버 (Client Key Exchange): 클라이언트가 서버의 공개 키 (server-cert.pem)로 대칭키를 암호화해서 서버로 전송
    RSA 비대칭키 방식 사용

    • RSA 비대칭키 방식이 사용되고, ca.pem이 클라이언트와 서버가 서로 인증서를 신뢰하는 데 필수적임

  4. 서버 → 클라이언트 (ChangeCipherSpec): 서버는 클라이언트가 보낸 대칭키로 데이터를 암호화하고, 이제부터 대칭키 방식으로 통신을 계속한다고 알림

    • 이때도 ca.pem을 통해 서버 인증서를 확인하여, 신뢰할 수 있는 서버인지 검증

  5. 클라이언트 → 서버 (ChangeCipherSpec): 클라이언트도 대칭키 방식으로 데이터를 암호화하고 통신 시작

  6. 실제 통신: 이제부터 클라이언트와 서버는 대칭키 방식으로 암호화된 데이터를 주고받으며 실제 통신 시작


- 파일 설명 📂

  • server-key.pem: 서버의 개인 키. 대칭키 암호화된 데이터를 복호화하거나 인증서 서명에 사용
  • server-cert.pem: 서버의 공개 키가 담긴 인증서. 클라이언트가 서버 신뢰 확인하고 대칭키 암호화에 사용
  • client-key.pem: 클라이언트의 개인 키. 서버와의 안전한 통신을 위해 사용
  • client-cert.pem: 클라이언트 인증서. 서버에 클라이언트의 신뢰성 전달하는 데 사용
  • ca.pem: CA (Certificate Authority) 기관이 서명한 인증서로, 서버와 클라이언트가 서로의 인증서를 신뢰할 수 있도록 도와줌


- 최종 정리 📝

  • RSA 비대칭키 통신은 Client Key Exchange에서 사용되고, 그 이후에는 대칭키 방식으로 암호화된 데이터를 주고받게 됨.
  • 대칭키는 속도가 빠르고 리소스를 적게 소모하기 때문에 실제 통신에 사용됨.


참고----------------------------------------------------------------------------------------------------------------

SSL과 TLS 비교 - 통신 프로토콜 간의 차이점 - AWS (AWS)

TLS(SSL) - 1. TLS의 암호화 방식(대칭키, 비대칭키) (개발자 소들이)

TLS란? | 네트워크 보안 프로토콜 | Cloudflare (Cloudflare)

OSI 모델이란? | OSI 7계층 | Cloudflare (Cloudflare)

도커 교과서 | 엘튼 스톤맨 - 교보문고

댓글

댓글 쓰기

이 블로그의 인기 게시물

[보안] CA인증서, 서버인증서, 클라이언트 인증서와 Openssl

이미지
📌​CA 인증서 ROOT 인증서로부터 시작하는 계층 구조    📍​ Root Certification, Intermediate Certification, Server Ceritification 루트 인증서(Root Certification) 최상위 인증 기관 (DigiCert, GlobalSign, GTS)이 발급하는 인증 운영체제(OS) 및 브라우저에서 기본적으로 신뢰하는 인증서 로 저장됨. 자체 서명(self-Signed) 이 되어있음 중간 인증서(Intermediate Certification) Root CA가 직접 웹사이트에 인증서를 발급하지 않고 중간 CA를 통해 인증서 발급 중간 CA는 루트 CA의 서명을 받은 인증 기관으로 직접적으로 서버 인증서를 발급 브라우저와 OS는 중간 인증서를 직접 신뢰하지 않지만 중간 인증서가 루트 CA에 의해 서명되었기 때문에 신뢰가 가능함 서버 인증서(Server Certification) 최종적으로 웹사이트에서 사용하는 인증서 중간 CA에 의해 서명됨 사용자의 브라우저는 루트 CA까지의 인증서 체인을 검증하여 인증서의 유효성을 확인 ✅​ 정리하면 루트 인증서 ➡️​ 중간 인증서 ➡️​ 서버 인증서 순으로 인증 체인이 이루어짐
자세한 내용 보기

HTTP/HTTPS 프로토콜의 개념과 작동 원리 (WireShark)

이미지
📌  HTTP/HTTPS? https://seo.tbwakorea.com/wp-content/uploads/2023/12/http-1.png HTTP(Hypertext Transfer Protocol) HTTP는 OSI 7 Layer에서  Application Layer 에 속함 HTTP는 숫자 코드 및 데이터 양식으로 다양한 유형의 HTTP 응답을 전송 200 - OK 🟩 ​ 302 - Found 🟨 400 - Bad Request 🟥 405 - Method Not Allowed 🟥 503 - Service Unavailable ❌ HTTPS(Hypertext Transfer Protocol Secure) = HTTP(Hypertext Transfer Protocol) + SSL(Secure Sockets Layer)  HTTPS는 HTTP의 확장 버전 (보안 강화) 📌  HTTP/HTTPS의 차이점 https://www.cloudflare.com/img/learning/security/glossary/what-is-ssl/http-vs-https.svg HTTPS를 사용하는 웹사이트 URL은 "https://" 로 시작함 HTTP는  "http://" HTTPS는 통신할 때  SSL/TLS  인증서를 이용해 통신 데이터를 암호화 HTTP는 HTTP/1 HTTP/2 TCP/IP를 사용하고 HTTP/3 QUIC 프로토콜을 사용함 Google에서 개발한 QUIC(Quick UDP Internet Connections) 기존의 TCP와 TLS를 개선하려는 목적에서 만들어짐 내장된 TLS 암호화 보유 UDP기반의 QUIC 프로토콜은 TCP기반의 HTTPS보다 월등히 빠름   특히 모바일 네트워크 환경에서 큰 성과를 거둠 (특히 Youtube 영상 버퍼 스트리밍) HTTPS는 SEO(Search Engine Optimization)...
자세한 내용 보기