DH Developement

TLS 핸드세이크

• 클라이언트 - 서버가 교환하는 일련의 데이터그램 == 메시지
• 사용되는 키 교환 알고리즘의 종류 및 양측에서 지원하는 암호 모음에 따라 달라짐
  • 1.3 버전 이전에는 RSA 키 교환 알고리즘을 사용했지만, 안전하지 않음

TLS 핸드세이크 작동 방식

• 비대칭 암호화(공개 키 - 개인 키) 사용

• TLS 핸드세이크
  • 클라이언트 헬로 메시지
    • 클라이언트가 서버로 Hello 메시지 전송하여 핸드세이크 개시
    • 이 때 TLS 버전, 지원 암호 제품군, 클라이언트 무작위 바이트 문자열 포함
  • 서버 헬로 메시지
    • 클라이언트 헬로 메시지에 대한 응답으로 서버의 SSL 인증서, 서버에서 선택한 암호 제품군, 그리고 서버에서 생성한 무작위 문자열 바이트 포함한 메시지 전송
  • 인증
    • 클라이언트가 서버의 SSL 인증서를 인증서 발행 기관을 통해 검증
    • 인증서에 명시된 서버인지, 상호작용중인 서버가 실제 해당 도메인의 소유자인지 확인
  • 예비 마스터 암호
    • 클라이언트가 무작위 바이트 문자열 하나 더 전송
    • 공개키로 암호화 되며, 서버 개인 키로만 해독 가능
    • 공개키는 서버의 SSL 인증서를 통해 클라이언트에 전달됨
  • 개인키 사용
    • 서버가 예비 마스터 암호를 해독함
  • 세션 키 생성
    • 클라이언트와 서버 모두 클라이언트 무작위, 서버 무작위, 예비 마스터 암호 이용해 세션 키 생성
    • 모두 동일한 결과가 나와야 함
  • 클라이언트 준비 완료
    • 클라이언트가 세션 키로 암호화된 완료 메시지 전송
  • 서버 준비 완료
    • 서버가 세션 키로 암호화된 완료 메시지 전송
  • 안전한 대칭 암호화 성공
    • 핸드세이크 완료, 세션키를 통한 통신이 진행
• 데이터가 암호화되고 인증되면, 메시지 인증 코드(MAC: Message Authorization Code)와 함께 서명됨

TLS(Transport Layer Security)란?

• 인터넷 상 커뮤니케이션을 위한 개인 정보 및 데이터 보안 용이하게 위한 하기 보안 프로토콜
• 즉 웹 브라우저/어플리케이션과 서버간 커뮤니케이션을 암호화 하는 포로토콜
  • 이메일, 메세지, VoIP(보이스오버) 등

TLS 역할

• 암호화: 제 3자로부터 전송되는 데이터 숨김
• 인증: 정보 교환 당사자가 요청된 당사자임을 보장
• 무결성: 데이터가 위조되거나 변조되지 않았는지 확인

사용 이유

• 데이터 유출 및 공격으로부터 웹 어플리케이션 보호 용도

TLS vs SSL

• SSL (Secure Sockets Layer): 보안 소켓 계층
• TLS는 SSL에서 발전한 버전
• 두개를 혼동하여 사용하는 경우가 많음. 현재는 TLS 를 주로 사용함

TLS vs HTTPS

• HTTPS는 HTTPS 프로토콜 상위에서 TLS 암호화를 구현한 것

TLS 인증서?

• 웹 어플리케이션이 TLS를 사용하기 위해선 원본 서버에 TLS 인증서가 설치되어야 함
  • SSL 인증서라고 혼동돼서 불리기도 함
  • 인증 기관이 도메인을 소유한 사람 혹은 비즈니스에 TLS 인증서 발행
• 서버의 공개키 및 도메인 소유자에 대한 정보 포함함
• 서버의 신원 확인하는데 사용됨

암호 제품군?

• 안전한 통신 연결 수립을 위한 알고리즘 세트

도커 네트워크

• 도커 네트워크는 일종의 내부망 이다.
  • 각 컨테이너들은 독립적인 네트워크 망을 가진다.
  • 정확히는 분리된 네트워크를 가진다 -> IP를 나눈다는 의미
  • 때문에 각 컨테이너별로 호스트와는 다른 가상의 IP 주소를 가진다.
• 도커 네트워크는 컨테이너가 끼리의 통신을 할 수 있는 범위라 말할 수 있을 것 같다.
• 기본적으로 컨테이너가 구동되게 되면 해당 컨테이너에 대한 default_network가 생성된다.
  • 이렇게 되면 다른 네트워크의 컨테이너와 소통할 수 없기 때문에 도커 외부로 우회하여 소통해야한다.
  • 컨테이너끼리 소통하기 위해 외부로 나갔다 들어와야 하기 때문에 성능적으로 저하가 발생하고, 보안적으로도 문제가 생길 수 있다.
• 그러나 동일한 네트워크에 속한 컨테이너들 끼리는, 컨테이너의 이름과 포트만으로 서로 통신이 가능하다.

컨테이너 구동 시 도커 네트워크 구성에 대해

• 컨테이너 구동 시, 순차적으로 도커 내부 IP 부여
  • 일반적으로 172.~~ 으로 시작하더라
  • 순차적으로 IP를 부여하기 때문에, 컨테이너를 내렸다 다시 올리면 컨테이너 IP가 변동 될 수 있음
• 도커 네트워크는 내부망이기에, 외부와 연결시켜야 함
  • 컨테이너 구동 시, 자동적으로 컨테이너 마다 호스트에 veth(Virtual Ethernet)라는 가상 네트워크 인터페이스를 생성함
  • 네트워크 관련 설정을 하지 않는다면 default0 브릿지를 사용함

Docker Bridge

• 도커 브릿지는 호스트와 컨테이너를 잇는 라우팅 경로
  • 즉 쉽게 말하면, 각 컨테이너에 가상의 IP를 부여하는 공유기 역할

도커 네트워크 전체 조회

• 현재 사용중인 도커 네트워크 리스트 조회

docker network ls

• 도커 네트워크 세부사항 조회

docker network inspect 

도커 네트워크 설정

• 도커 네트워크 설정
• docker network create <네트워크 이름>

컨테이너 네트워크 설정

• 같은 도커 네트워크에 해당하는 모든 컨테이너들은 서로 내부 통신이 가능함
  • 이미 db_mariadb 라는 컨테이너가 proxy라는 도커 네트워크 안에 구동되어 있다면
  • 지금 올리는 어플리케이션 컨테이너를 proxy라는 네트워크에 포함시킴으로 인해서, db_mariadb:3306 을 url로 잡으면 통신이 가능해짐
  • 같은 네트워크가 아니라면, 'HostIP:컨테이너 포트' 를 통해 접근할 수 있음
    • 문제는 컨테이너가 호스트에 포트를 열어둔게 아닌, 컨테이너 포트만 노출 시킨 상태라면 접근할 수 있는 방법이 없어짐
• 컨테이너 네트워크 설정 - docker compose
  • external: 컨테이너 구동 시 새로운 네트워크를 사용할지에 대한 여부를 설정하는 것
    • true: 기존 도커 네트워크를 할당함
    • false: 새로운 도커 네트워크를 생성함

  services:
      app:
          // 컨테이너 설정
          networks:
              - proxy
  
  networks:
      proxy:
        # proxy라는 새로운 네트워크를 생성하는게 아닌, 기존의 proxy라는 네트워크를 사용한다는 의미
          external: true

• 컨테이너 네트워크 설정 - Dockerfile

    docker run app_name --net proxy