HTTPS/SSL 이란

여러 프로젝트를 진행하며 배포와 도메인을 적용하는 과정 중 NginxProxyManager를 사용하여 적용하였다.

홈서버 리버스 프록시 적용하기 (feat. Nginx-Proxy-Manager)

저의 홈서버에는 여러가지 서비스가 올라가있습니다. GitLab, WireGuard, Bitwarden, jenkins 그리고 각종 사이드 프로젝트 등.. 이 각 서버에 접속하려면 각각의 포트번호와 ip 주소 등을 통해 접속해야 하는데 영어단어 암기도 고통스러워하는 저한테는 너무나 어려웠죠 게다가 외부에서 접속하려면 일일이 포트포워딩까지 진행해야 하는 그런 번거로운 과정까지 어찌나 지독하던지.. Nas 서버 (Synology) 관련 설정중 역방향

BM-Developer검정색 마시멜로

덕분에 자연스럽게 SSL 적용과 번거로운 인증서 업데이트 등 관련 문제를 스킵할 수 있었다.

하지만 이제와서보니 이 문제를 너무 쉽게? (NginxProxyManager 가 처리해 주다 보니..) 지나오다 보니 관련 내용에 대해 깊게 고민해보지 않았던거같아 이제서야 밀린숙제를 진행해본다.

HTTP vs HTTPS

HTTP 의 보안적인 약점을 해결하기위해 사용됨

• 보안적 약점
  • 위조
• 감청
• 해결방법
  • SSL/TLS 계층을 통해 암호화

SSL 디지털 인증서

클라이언트와 서버간 통신을 제 3자가 보증해주는 문서

• 역할
  • 통신 내용이 공격자에게 노출되는것을 방지
  • 접속하려는 서버가 신뢰할 수 있는지 판단
  • 통신 내용에 대한 위조/변조 방지
• 포함된 내용
  • 신뢰할 수 있는 서버임을 보장
    • 서비스의 정보 (인증서를 발급한 CA, 서비스 도메인 등)
• SSL 통신에 사용할 공개키를 클라이언트에게 전달
  • 공개키 내용, 공개키 암호화 방법

신뢰할 수 있는 서버임을 보장

CA (Certificate authority) : 클라이언트가 접속한 서버가 의도한 서버가 맞는지 보장하는 역할을 하는 기업

• 웹브라우저 서버에 접속 => 서버가 클라이언트 에게 인증서를 제공
• 제공받은 인증서를 발급한 CA가 브라우저 내장 CA 리스트 에 포함되어있는지 확인
  • 브라우저 내장 CA 리스트에 있다면
    • 인증서에 있는 공개키를 통해 인증서를 복호화를 시도한다.
      • 복호화 성공 시
        • 서버의 비공개 키로 암호화 된 정보임을 보장 받음 (신뢰)
      • 실패 시
        • 서버의 비공개 키로 암호화되지 않음 == 다른 서버
  • 없다면
    • 인증되지 않은 기관 == 신뢰할 수 없는 인증서

통신 내용이 공격자에게 노출되는것을 방지

• 비대칭키(공개키)를 사용하여 암호화
  • KeyA: 비공개 키
  • KeyB: 공개 키
  • keyA 로 암호화 => keyB 로 복호화
  • keyB 로 암호화 => keyA 로 복호화
• 클라이언트 => 서버 요청
  • KeyB(공개키) 를 통해 암호화 후 서버에게 요청
  • 서버측은 암호화 된 내용을 KeyB (비공개 키) 를통해 복호화

접속하려는 서버가 신뢰할 수 있는지 판단

• 서버 => 클라이언트 응답
  • KeyB (공개키) 로 복호화가 된다?!
  • 해당 응답은 KeyA(비밀키) 로 암호화가 된거구나!!
  • 비밀키를 아는 곳은 저 서버밖에없어!!

• SSL == TLS ?
  • 네스트케이프 에서 SSL 발명 => 표준화 기구(IETF) 관리로 변경 => TLS 변경