[0812~0818] 암호화와 인증

6주차!

벌써 6주차! 혼공단의 마지막 주가 되었다..
언제 6주차까지 끝내지라고 생각했는데, 하루하루 다른 일들도 하면서 보내다보니 벌써 8월 끝자락에 왔다.
마지막까지 화이팅해서 글을 작성해보자!

현재 백엔드를 공부하면서 서버를 배포할 일이 생겼는데
AWS에 배포한 백엔드와 프론트가 HTTPS, HTTP 충돌이 났다.
충돌방지를 위해 인증서를 발급받아서 HTTP도 허용을 하도록 해라- 라는데..
SSL? TLS? 들어는 봤지만 정확히 쟤네가 뭔지를 모르니까 머리가 터지려던 찰나!
6주차 내용에서 이와 관련된 챕터가 있어서 딱 타이밍 좋게 공부할 수 있었다.

오늘의 게시 내용은 이거다!

[이번 주차 숙제✍️]

쓰리 웨이 핸드셰이크상에서 다음 세그먼트의 Acknoeledgment number는 ?

→ 그림에 표시된 그 전 raw값이 3588415412니까 이 담은 +1한 값인 3588415413

다음 그림은 두 호스트 TLS 핸드셰이크를 하는 과정이다. TLS 관련 메시지로 알맞은 것?

③ServerHello

[암호와 인증서]

• 암호화: 원문 데이터 → 🤔: 얘를 어떻게 알아볼까..?
• 복호화: 암호화된 데이터 → 원문 데이터

암호화와 복호화는 안전한 데이터 송수신 + 인증서 기반의 검증 가능!

암호화와 복호화의 핵심은 뭐다? ‘🔑 (키)’

[대칭 키 암호화 방식과 공개키 암호화 방식]

💡대칭키 암호화

• 암호화, 복호화에 동일한 🔑 사용
• ‘동일한 🔑’ ➡️ ’대칭 🔑’
• 적은 부하 ➡️ 암호화 및 복호화 빠르게 수행

하지만 한 가지 문제가 있다!

바로바로.. 상대방에게 안전하게 🔑 를 전달하기 어렵다는 것! (두둥)

동일한 🔑 를 사용하기에 🔑 가 유출될 가능성도 높아지는데 유출되면 중요한 정보를 암호화한 의미가 사라진다.
그래서 이러한 점을 보완하기 위해 등장한 것이 바로 "공개 키 암호화"

💡공개 키 암호화(비대칭 키 암호화)

• 단일한 키를 사용한 대팅 키 암호화 달리, 암호화/복호화 방식에서 사용한 키가 다름
• 공개 키(암호화): 🗝️, 개인 키(복호화): 🔑 ➡️ 키 안전하게 공유 가능
• 암호화, 복호화에 시간과 부하 상대적으로 많이 든다.
  

[인증서와 디지털 서명]

네트워크에서 사용되는 인증서란? ➡️ 공개 키 인증서

💡공개 키 인증서

• 공개 키와 공개 키의 유효성 입증

🤔: “전송 도중에 조작된건 아니지?”

🤔: “누가 만들었는지, 유효기간은 언제까지인지, 조작은 안되었는지 포함해서 인증 기관에서 인증서 만들면 ㅇㅋ해줌”

💡인증 기관 (Certification Authority)

• 제 3의 기관
• 인증서 발급, 검증, 저장 역할 수행
• 서명값(signature) “내가 이 인증서 보증한다. ✍️”
  • 인증서 내용에 대한 해시 값 ➡️ CA의 개인 키로 암호화 하는 방식으로 생성
    • 해시 값: 임의의 길이의 데이터를 고정된 길이의 데이터로 변환해주는 함수를 적용시킨 결과 값.
      • 데이터 조금만 달라져도 값이 완전히 바뀐다.

[HTTPS: SSL과 TLS]

인증과 암호화를 수행하는 프로토콜

• SSL: Secure Sockets Layer
• TLS: Transport Layer Security

TLS ➡️ SSL을 계승한 프로토콜

이 둘의 작동 과정은 사용되는 암호 알고리즘과 버전에 따라 세부적인 차이는 있겠지만 크게 보면 비슷하다.

SSL/TLS를 사용하는 대표적인 프로토콜 ➡️ HTTPS

HTTPS는 안전한 송수신을 위해 개발된 프로토콜

TLS 1.3을 기반으로 HTTPS가 동작하는데 HTTPS는 크게 3단계를 거쳐서 송수신된다.

1️⃣ TCP 쓰리 웨이 핸드셰이크
2️⃣ TLS 핸드 셰이크
3️⃣ 암호화된 메시지 송수신

TCP 쓰리 웨이 핸드셰이크는 4주차에서 학습했었다!
간단하게 복습해보자면 두 호스트가 SYN, SYN+ACK, ACK 플래그가 설정된 TCP 세그먼트를 주고 받는 것이다.

다음으로 2번째 단계인 TLS 핸드 셰이크!

얘의 핵심은 2가지.

1️⃣ 암호화 통신을 위한 키를 교환한다.

2️⃣ 인증서 송수신과 검증이 이뤄진다.

먼저 클라이언트가 암호화된 통신을 위해 서로 맞춰 봐야 할 정보를 제시하는 메세지(ClientHello)를 보낸다.
여기에는 지원되는 TLS 버전, 사용 가능한 암호화 방식과 해시 함수(암호 스위트: Cipher suite) 등등이 포함되어있다.

서버는 ClientHello에 대한 응답으로 ServerHello 메세지를 전송.
클라이언트가 전송한 것은 암호화 이전에 맞춰 봐야 할 정보를 제시한다면, 서버에서는 제시된 정보를 선택한다.

서로 ClientHello, ServerHello를 주고받으면 암호화된 통신을 위해 사전 협의해야 할 정보가 결정된다.
이렇게 결정된 정보를 가지고 암호화에 사용할 키를 만들어낸다!

서버는 또 Certificate(인증서), CertificateVerify(디지털 서명) 메세지를 전송한다.
클라이언트는 이 메세지를 토대로 서버의 공개 키를 검증한다.

이런 방식을 통해서 암호화에 사용할 키와 인증서를 주고받을 수 있다라는 점!