Https

Http

인터넷에서 데이터를 주고받을 수 있는 프로토콜

프로토콜=규칙

 

ex) https://www.naver.com
http형식으로 메시지를 줄꺼야! 나한테 메시지를 줄 때도 http형식으로 줘!

 

Https를 사용하는 이유

1. 보내는 데이터 탈취 방지
- Http로 데이터를 보내면 데이터가 raw하다.
- Https는 데이터를 암호화해서 탈취를 방지한다. 

2. 서버가 검증된다. 
- CA를 통해 검증할 수 있다. 

---

Https(Hyper Text Transfer Protocol Seure)

Http의 보안 버전

1. 내가 서버에 보내는 정보들을 제3자가 못 보게 한다.(암호화)
2. 접속한 서버가 신뢰할 수 있는 곳인지 알려준다.

Http	Https
네이버인 줄 알고 링크를 클릭했더니 네이놈 개인정보(아이디, 비밀번호)입력 그 정보를 가지고 네이놈은 네이버 계정 접속 시도	네이버인 줄 알고 링크를 클릭했더니 네이놈 기관에 검증된 사이트만 https 사용을 허가 http을 사용하는 사이트들은 주소창에 Not secure 표시

대칭키 방식 

클라이언트와 서버가 암호화, 복호화할 수 있는 같은 키를 공유

 

대칭키의 한계

클라이언트가 서버와 같은 키를 가지려면 서버에서 클라이언트에게 키를 전송해주는 과정이 필요하다.

1. 만약, 서버-> 클라이언트로 키를 전송 중 제3자가 탈취한다면?
2. 키가 정품인지 어떻게 알지? 네이버가 아니라 네이놈의 공개키라면?

 

비대칭키=공개키, 개인키

• A키를 암호화하면 B키로만 복호화 가능
• B키로 암호화하면 A키로만 복호화 가능
• B키가 서버만 가지고 있는(개인키), A키는 전체 공개된 키(공개키)

 

1번 문제: 키를 제3자가 탈취한다면? 

클라이언트에서 서버로 암호문(A키로 암호화) 전송을 가정해보자. 비대칭키 방식이므로 A키는 B키(개인키)로만 복호화 가능하다. 만약 제3자가 중간에 암호문을 탈취해도 제3자는 A키(공개키)만 알고 있으므로 암호문을 복호화할 수 없다.

 

2번 문제: A키가 정품인지 어떻게 알지? 

정품을 인증해주는 공인된 민간기업: Certificate Authority(CA), CA는 브라우저(크롬, 사파리, 파이어폭스, 엣지, 익스플로우...) 에 내장돼 있다.

 

Https의 데이터 요청 과정

Handshake(악수): 일종의 탐색과정

• 클라이언트는 랜덤 데이터를 서버에 보낸다.
• 서버는 다른 랜덤 데이터와 서버의 인증서를 실어 클라이언트에 보낸다. 
• 클라이언트는 받은 인증서를 브라우저에 내장된 CA정보들을 통해 확인한다. 

 

CA에 인증을 받은 인증서들은 해당 CA의 개인키로 암호화돼있다.

인증서가 정품이라면 브라우저에 내장된 CA의 공개키로 복호화 가능하다. 

복호화된 인증서는 서버의 개인키를 포함하고 있다. 

복호화 O= 인증서가 정품이다= 신뢰할 수 있는 서버이다.
복호화 X= 브라우저 주소창: Not secure

 

Https는 대칭키와 비대칭키를 혼합해서 사용

Why? 비대칭키가 무조건 좋은 거 아닌가? 

비대칭키 방식으로 암호화/복호화하는 건 컴퓨터에 큰 부담을 준다. 

전송할 데이터는 대칭키로 암호화한다. 여기서 의문이 들 것이다. 대칭키는 제3자에게 탈취당할 수 있지 않나?

대칭키를 공유(전송)할 때 비대칭키를 사용하면 탈취 문제를 해결할 수 있다. 

• 클라이언트는 Handshake 할 때 생성된 두 랜덤 데이터를 혼합해서 임시키를 만든다. 
• 임시키는 서버의 공개키로 암호화 후 서버로 전송된다. 
• 서버는 암호화된 임시키를 개인키로 복호화한다. 
• 클라이언트와 서버는 동일한 임시키(대칭키)를 가진다. 

임시키(대칭키)를 비대칭키 방식으로 공유했기 때문에 제3자가 탈취할 수 없다. 

 

 

출처: https://www.yalco.kr/31_https/