반응형
⌨️ HTTP의 약점
- 평문(암호화 하지 않는) 통신이기 때문에 도청가능
- 인터넷은 전세계를 공유하고 있는 네트워크 구성이유때문
- 통신 상대를 확인하지 않기때문에 위장가능
- 누가나 리퀘스트 할 수 있다
- 어디에서 누가 리퀘스트 할 수 있는지는 알 수 가 없다
- 완전성을 증명할 수 없기 때문에 변조가능
- 완전성 : 정보의 정확성
- 리퀘스트나 리스폰스에서 발신한 후에 받는 시점에 정보가 위조 됐다도 하더라도, 이 사실을 알 수 없다
🖥️ HTTP + 암호화 + 인증 + 완전성 = HTTPS
- HTTPS는 SSL의 껍질을 쓴 HTTP 이다
- 기존 HTTP 구조
- HTTPS 구조
📠 암화화 방식
SSL를 사용하기 전에 두가지 암호화 방식에 대해 이해를 할 필요가 있습니다.
SSL를 사용하기 위해서는 "공통키","공개키" 방식을 이해해야 합니다
공통키
- 암호화 / 복호화시에 같은 키를 이용하는 것을 공개키 방식
- 공개키 암호화의 문제 : 키를 같은것을 공유해야 하는데, 키를 공유하는 과정에서 누군가 탈취가 가능하다
공개키
- 공개키와 비공개키를 사용하며, 공개키는 외부에 공개되어도 되지만, 비공개키는 외부에 노출이 되면 안되는 키이다.
- 공개키/비공개키는 한 쌍이며, 공개키를 외부에 전달하여, 공개키를 통해 암호화하고 비밀키를 통해 복호화를 한다
🎚️ HTTPS 하이브리드 시스템
- 메세지를 주고 받을때마다 공개키 방식을 사용할 경우, 처리속도가 느려짐 그리하여 공통키를 공개키를 이용하여 암호화하여 전달 , 이후에는 공통키를 통해 암호화/복호화
🎛️ 공개키를 어떻게 “안전하게”전달할 것인가
HTTPS는 공개키를 이용을 하지만, 공개키 조차 중간에 탈취할 가능성이 있다.
그리하여 CA를 통해 공개키를 검증하는 방식을 사용한다
CA : 클라이언트와 서버가 신뢰하는 인증기관
아래 그림처럼 서버의 공개키를 인증기관에 전달하고 서버의 공개키를 제출하면 인증기관에서 공개키 + 디지털서명을 전달하며,
공개키 + 디지털서명을 클라이언트에게 전달한다. 디지털서명은 브라우저내의 인증기관의 공개키를 활용하여 검증한다
⏰ HTTPS 통신과정
1.HandShake : Client Hello
- SSL버전지정, 암호화 방식을 전달
2.HandShake : Server Hello
- SSL버전 지정,암호화방식 전달(여기서는 클라이언트에서 제공한 SSL방식,암호화 방식 선택된것을 전달)
3.HandShake : certificate
- 공개키 증명서 전달
4.HandShake : Server Hello Done
- 최초의 SSL 협상 완료
5.HandShake : Client Key Exchange
- 통신을 암호화 하는데 사용하는 Pre Master Secret 전달
- Pre Master Secret : Master Secret를 계산하기 위한 값이며, Master Secret는 데이터암호화 하는데 사용된다
6.Change Cipher Spec
- 암호화키를 사용하겠다는 신호
7.HandShake: Finished
8.Change Cipher Spec
- 서버에서 암호화키를 사용하겠다는 신호
9.HandShake : Finished
- 서버에서 부터 Finished 전달
10.HTTP Request
11.HTTP Response
12.Cloes-notify
- 클라이언트가 접속을 끊음
반응형
댓글