HTTP를 먼저 알아보자
HTTPS는 SSL(Secure Socket Layer)을 이용한 HTTP 통신 방식입니다. (HTTPS : HTTP over Secure Socket Layer)
따라서 HTTP에 대해 먼저 간단하게 알아보겠습니다.
HTTP : Hyper Text Transfer Protocol
-
Hyper Text를 전송하기 위해 만든 프로토콜
-
HTTP는 클라이언트 (웹 브라우저) ↔ 서버 사이의 요청/응답 프로토콜입니다.
-
웹상에서 통신을 할 때 사용됩니다.
-
http://naver.com : "naver.com과 통신을 하는데 HTTP 프로토콜을 활용해서 통신하겠다"는 의미입니다.
HTTP의 약점
하지만 HTTP에는 3가지 약점이 있습니다.
-
암호화하지 않은 통신이기 때문에 도청할 수 있다.
통신 경로 상에 있는 네트워크 기기나 케이블이나 컴퓨터 등을 전부 자기 자신이 소유할 수는 없습니다. 악의를 가진 사람이 기기를 통해 통신 내용을 도청할 수 있습니다.
-
통신 상대를 확인하지 않기 때문에 위장할 수 있다.
- (Request의 출처) Client를 확신할 수 없다.
- HTTP는 누가 Request를 보내도 Response하는 구조입니다. 신원이 보장된 특정 Client와만 통신할 수 없습니다.
- 또한 대량의 Request를 통한 Dos 공격의 위험이 있습니다.
- (Response의 출처) Server를 확신할 수 없다.
- Response를 보낸 Server가 내가 의도한 Server인지 확신할 수 있습니다. 위장 Server라는 위험성이 있습니다.
-
완전성을 증명할 수 없기 때문에 변조 할 수 있다.
완전성: 정보의 정확성
Client와 Server가 보낸 정보를 중간에 누군가 바꿀 위험성이 있습니다.
HTTP란?
- HTTP에 SSL의 껍질을 씌운 것
- HTTPS는 HTTP와 별개인 새로운 프로토콜이 아닙니다.
- HTTP는 보안에 취약하기 때문에 HTTP에 다른 보안 프로토콜을 조합한 것
- HTTP 통신을 하는 소켓 부분을 SSL이나 TLS 프로토콜로 대체합니다.
- SSL (Secure Scoket Layer)
- HTTP와 독립된 프로토콜
- HTTP 외에도 다방면으로 사용되고 있습니다.
- (참고) 공부하다가 보면 TLS 에 대한 언급을 볼 수 있습니다.
- SSL == TLS 같은 말입니다. 네스케이프에 의해서 SSL이 발명되었고, 이것이 점차 폭넓게 사용되다가 표준화 기구인 IETF의 관리로 변경되면서 TLS라는 이름으로 바뀌었다. TLS 1.0은 SSL 3.0을 계승한다. 하지만 TLS라는 이름보다 SSL이라는 이름이 훨씬 많이 사용되고 있다.
SSL을 활용한 통신 방법
SSL을 사용하면 암호화를 할 수 있고, 통신하려는 상대를 보증할 수 있습니다.
Client Server 통신에 앞서 Server는 CA에서 인증서를 받는습니다.
CA
- CA(Certificate authority)
- 공인된 기관에서 Server가 믿을 수 있는 서버인지 보증하는 SSL 보증서를 발급합니다.
- CA기관마다 보안 강도가 다르기도 합니다.
- 뒤에 실습에서 살펴볼 인증서는 보안 강도가 약한 수준이지만, 보안 수준이 높은 인증서는 사업자등록증까지 요구한다고 합니다.
- 자체 CA (사설 CA)로도 SSL 인증서를 발급할 수 있습니다.
- 사설 CA도 HTTPS 통신입니다. 하지만 브라우저 입장에서는 안전하지 않다고 판단합니다.
통신 방법
- Client가 Server에 최초 접속하면서 2가지 정보를 보냅니다.
- random data
- Client가 생성한 random data입니다.
- 이건 나중에 사용됩니다.
- 암호화 기법 목록을 보냅니다.
- SSL에서 사용되는 암호화 기법은 여러가지입니다.
- Server는 3가지 정보를 보냅니다.
- random data
- Server가 생성된 random data입니다.
- Client가 보낸 암호화 기법 중 자신도 사용할 수 있고, 가장 안정된 암호화 기법
- 인증서
- 인증서에는 서비스 정보와 public key를 보냅니다.
- 서비스 정보: 인증서를 발급한 CA, 서비스의 도메인 등등
- 서비스 정보는 private key로 암호화된 상태입니다.
- (1) Client는 믿을 수 있는 CA에서 발급한 인증서인지 확인합니다.
- Browser는 믿을 수 있다고 판단한 CA 기관 목록을 가지고 있습니다.
- 공인 CA (믿을 수 있는 CA) / 사설 CA에서 발급한 인증서는 각각 다른 형태로 표시됩니다.
- (2) Client는 실제 CA 기관에서 발급한 인증서인지 확인합니다.
- Server가 보낸 인증서에는 서비스 정보와 public key가 있습니다.
- private key와 public key는 하나의 쌍을 이룹니다.
- public key로 암호화 → private key로 복호화
- private key로 암호화된 서비스를 public key로 복호화할 수 있다면,
- 두 key는 pair입니다.
- CA 기관에서 발급한 인증서라고 할 수 있습니다.
- 즉, 내가 기대한 서버인지 확인하게 됩니다.
⇒ 대칭키 방식 (public, private key를 사용하는 암호화 방식)
- 통신에 사용할 key를 Client와 Server는 공유합니다. ⇒ 공통키 방식 (하나의 key를 공유하는 암호화 방식)
- premaster secret은 앞서 언급한 random data를 합쳐 생성합니다.
- public key로 암호화하면 private key로만 복호화할 수 있기 때문에 premaster secret은 안전합니다.
- premaster secret → master secret → session key
- 일련의 과정을 거쳐 client와 server는 공통키를 가지게 됩니다.
- 공통의 session key로 데이터를 암호화/복호화할 수 있습니다.
왜 이런 방식을 취할까?
위와 같은 암호화 방식을 하이브리드 암호 시스템이라고 합니다.
주목해야 할 점은 대칭키 (1개의 키) 방식을 취하되, 그 키를 공유할 때 공개키 (public key, private key) 방식을 취한다는 점입니다.
- 대칭키
- 한 개의 key로 암호화 복호화
- 속도가 빠르다.
- 탈취의 위험이 있다.
- 비대칭키 (공개키, 비밀키)
- 공개키로 암호화, 비밀키로 복호화
- 속도가 느리다.
- 인증의 기능까지 제공한다.
대칭키의 단점 (1개의 키를 공유하면서 해킹당할 수 있는 위험), 공개키의 단점 (속도가 느리고, 많은 컴퓨팅 파워가 필요) 모두를 보완하는 방법입니다.
잘 보고 갑니당~~!!