HTTP 박살내기 프로젝트 - 9 | 인증, HTTPS

본 게시글은 <HTTP 완벽 가이드> 서적을 읽고 공부를 위해 요약한 게시글입니다

 

 

인증, 다이제스트 인증 이 파트 할까말까 고민했는데 그냥 하기로 했다

---

 

# 인증

인증은 내가 누구인지를 증명하는 것이다. 

 

 

1. 클라이언트: 문서를 주세요! (GET)

2. 서버: 문서를 받으려면 인증을 먼저 해주세요 (401 Unauthorized 응답 + WWW-Authenticate 헤더)

3. 클라이언트: 인증 정보를 서버로 준다 (GET + Authorization 헤더에 인증 파라미터를 담아 전송)

4. 서버: 인증 확인 이후 문서를 클라이언트에게 제공한다 (200 OK 응답 + 문서 전송)

 

 

* 클라이언트가 Authorization 헤더에 인증정보를 담아 전송할 때, base-64 방식으로 인코딩하여 전송한다.

 

"base-64는 바이너리 데이터를 문자 코드에 영향을 받지 않는 공통 ASCII 문자로 표현하기 위해 만들어진 인코딩이다."  <나무위키>

 

HTTP 헤더에서 사용할 수 없는 문자(큰따옴표, 콜론 등..)를 사용할 수 있게 해주고, 사용자 ID/PW 문자를 섞을 수 있기 때문에 (적어도 원문 그대로 전송은 아니기 때문에) ID/PW 노출 문제를 예방하는데 도움이 된다.

 

** base-64 인코딩은 암호화(해싱) 알고리즘이 아님 **

 

<기본 인증의 문제점>

1. Base-64로 인코딩된 문자열은 디코딩하면 원문을 얻을 수 있기 때문에 사실상 원문 그대로 전송하는 것과 같다.

-> 이를 예방하기 위해서는 HTTPS or 다이제스트 인증 프로토콜을 사용해야 한다.

2. Base-64로 인코딩된 문자열을 굳이 디코딩해서 알아낼 필요도 없고 그냥 복사 붙여넣기해도 정상 인증된다..;;;;

3. 가짜 서버(IP를 위장한)의 요청에도 내 인증 정보를 넘겨줄 수 있다 (스푸핑 공격)

 

=> HTTP 프로토콜이 보안에  취약하다는 말이 이런 이유에서 나오는 것이다.

HTTPS 프로토콜을 사용해서 인증된 서버에만 내 인증 정보를 보내고, 인증 정보를 암호화 해서 해커가 알아낼 수 없게 해야한다. (공개키(비대칭키) 방식 사용)

 

https://developers.google.com/search/docs/advanced/security/https?hl=ko

 

 

* 기본 인증에서 보안 기능이 강화된 "다이제스트 인증" 방식이 있으나, 널리 사용되지는 않음.

<다이제스트 인증 요약>

1. 비밀번호를 절대로 네트워크를 통해 평문으로 전송하지 않는다 (핵심) - MD5 암호화

2. 인증 체결을 가로채서 재현하려는 악의적인 사람들을 차단한다

3. 메시지 내용 위조 및 공격을 막는다

 

 

.. 모르겠고 그냥 HTTPS 씁시다!

책에 HTTPS 내용이 한무더기인데 이걸 다 정리하기는 그렇고 핵심 위주로 간략하게만 보기로 하자

 

< HTTPS 배우기 전 기초상식 >

# 대칭키 암호화 

암호화를 할 떄 사용하는 키와 복호화를 할 때 사용하는 키가 같다.

따라서 송신자와 수신자가 같은 키를 가지고 있어야 한다. 

 

따라서, 대칭키를 외부에 유출하지 않고 서로 안전하게 교환하는 것이 대칭키 암호화의 핵심이다.

장점: 암복호화 처리속도가 빠른 것이 특징.

단점: 키를 최소 1번은 상대에게 전달해줘야 한다는 근본적인 취약점이 존재한다 (대칭키의 한계)

대표적인 대칭키 알고리즘으로는 DES, RC2, RC4가 있다.

 

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

암호화/복호화 할 때 사용하는 키가 서로 다르다.

 

 

A키와 B키가 있다. 

A 키로 암호화를 하면 B 키로만 복호화를 할 수 있고

B 키로 암호화를 하면 A 키로만 복호화를 할 수 있다. (!!핵심!!)

 

서버는 A키와 B키를 모두 갖고있고, 그중 하나인 B키를 모두에게 공개한다(공개키)

클라이언트는 메시지를 공개키 B키를 이용해 암호화 하여 서버에게 보낸다.

서버는 공개키 B키로 암호화된 메시지를 개인키 A키를 이용하여 복호화한다.

(중간에 누군가가 메시지를 탈취하더라도, 개인키 A키 이외에는 복호화 할 수 없으므로 안전하다.)

 

특징: 송신자와 수신자 간 키 교환이 필요가 없다

단점: 대칭키에 비해 느리다

대표적인 알고리즘으로 RSA 알고리즘이 있다.

 

 

또한, 이를 이용하면 서버가 내가 신뢰할 수 있는 서버인지를 확인할 수 있다.

서버는 자신이 가지고 있던 개인키 A키로 암호화 하여 클라이언트에게 응답을 주면,

클라이언트는 공개키 B키로만 복호화를 할 수 있기 때문에 이 서버가 신뢰할 수 있는 서버임을 확인할 수 있다.

(만약 다른 서버라면 개인키 A키를 갖고있지 않기때문에 공개키 B키로 복호화되지 않음)

 

또한, 대칭키 알고리즘과 비대칭키(공개키) 알고리즘을 섞어서 사용할 수도 있다.

1회 대칭키를 교환하는 과정에서 비대칭키 방식으로 대칭키를 안전하게 교환하고,

이후로는 대칭키를 사용하여 빠르게 암복호화를 하는 방식이다! 

 

# HTTPS (HTTP Secure)

모든 HTTP 메시지는 SSL 계층을 거쳐 암호화 된다.

암호화된 메시지는 TCP 계층을 거쳐 TCP 세그먼트를 만들고 (포트번호 추가)

-> IP 계층을 거쳐 IP 패킷을 만들고 (IP주소 추가)

-> 네트워크 연결 계층을 거쳐 프레임을 씌운 후 다른 컴퓨터로 패킷이 전송된다.

 

 

SSL Handshake

HTTPS는 SSL Handshake 과정을 먼저 거쳐야한다.

 

1. 클라이언트가 암호 후보들을 보내고 서버에게 인증서를 요구한다
2. 서버는 선택된 암호와 인증서를 보낸다
3. 클라이언트는 인증서를 검증한다 (인증서가 참이라면, 인증서 내부에 서버의 공개키가 포함되어 있다.)
4. 클라이언트는 대칭키를 생성, 공개키를 이용해 암호화하여 서버에게 전송한다.
5. 이후 클라이언트와 서버는 대칭키를 이용해 메시지를 주고받는다

 

* 서버가 신뢰할 수 있는 서버인지 검증할 수 있는 인증서는 "CA(Certificate Authority)"에서 발급한다.

- 인증서는 CA의 개인키로 암호화 되어있다

- 클라이언트는 CA의 공개키로 인증서를 복호화해 열어볼 수 있다.

 

 

 

아하!

그렇구나 :D