HTTP & HTTPS

1. HTTP란 ?

Hyper Text Transfer Protocol의 줄임말로 서버와 클라이언트 사이에서 데이터를 주고받는 프로토콜이다.

여기서 데이터라는 것은 이미지, 텍스트, 영상, JSON 등으로 거의 모든 데이터를 전송할 수 있다.

 

1-1. 만든 사람

HTTP는 월드 와이드 웹을 설계한 팀 버너스 리(Tim Berners Lee)에 의해 처음으로 설계되었다.

HTTP는 www기반에서 세계적인 정보를 공유하는 데 큰 역할을 했다.

 

1-2 HTTP 구조

HTTP는 전송계층인 TCP 위에서 동작한다. 상태를 가지고 있지 않는 Stateless 프로토콜이며 

Method, Path, Version, Headers, Body 등으로 구성된다.

 

1-2-1. Stateless 프로토콜

server는 client가 보낸 상태를 저장하지 않는다. 예를 들어 내가 옷을 주문했다고 가정해보자.

stateful 프로토콜

나 : 이 옷은 얼마인가요 ?

점원 : 5만원 입니다.

나 : 그럼 2개 살게요.

점원 : 10만원 입니다. 카드, 현금 중에 어떤 걸로 주문하시겠어요 ?

나 : 현금으로 결제하겠습니다.

점원 : 10만원 결제 완료했습니다.

 

stateful 프로토콜의 문제점
점원(서버)이 중간에 바뀌는 상황

나 : 이 옷은 얼마인가요 ?

점원A : 5만원 입니다.

나 : 그럼 2개 살게요.

점원B : 무엇을 2개 산다는 말이죠 ?

나 : 현금으로 결제하겠습니다.

점원C : 무엇을 몇개를 현금으로 결제하시겠다는 건가요 ?

 

stateless 프로토콜

나 : 이 옷은 얼마인가요 ?

점원 : 5만원 입니다.

나 : 이 옷 2개 살게요.

점원 : 10만원 입니다. 카드, 현금 중에 어떤 걸로 주문하시겠어요 ?

나 : 이 옷 2개를 현금으로 결제하겠습니다.

점원 : 10만원 결제 완료했습니다.

 

stateless는 서버에서 필요한 정보를 그때 그때 담아서 보내주기 때문에, 서버가 바뀌더라도 상태정보를 알려줄 필요가 없다.

즉, 다른 서버로 매칭되어도 필요한 정보를 다 주기 때문에 정상적으로 서버에서 응답을 보내줄 수 있다.

 

1-2-2. Method

서버가 수행해야 할 동작

GET, PUSH, PUT, DELETE가 있다.

 

1-2-3. Path

요청대상, 즉 경로이다.

/로 시작하는 것은 절대경로로 시작한다는 말이다. 

 

1-2-4. Version

HTTP 버전을 나타낸다.

 

1-2-5. Headers

HTTP 전송에 필요한 모든 부가정보를 담고 있다.

요청 클라이언트 정보, 서버 에플리케이션 정보, 캐시 관리 정보, ... 등등

 

1-2-6. Body

실제로 전송할 데이터를 담음

위에서 말했듯이, 거의 모든 데이터를 전송할 수 있음. 다른 말로 byte로 표현할 수 있으면 보낼 수 있음

 

2. HTTP 장점

1. 비 연결성

2. 무 상태성

 

2-1. 비 연결성, 무 상태성

클라이언트에서 요청을 보내고 서버가 정상적인 응답을 보냈다면 TCP 연결을 끊는다.

그럼 데이터의 연결을 유지하기 위해 상태정보 등을 저장하기 위한 자원을 많이 쓰지 않기 때문에,

최소한의 자원으로 서버 유지를 가능하게 한다.

 

3. HTTP 단점

1. 비 연결성, 무 상태성

2. 평문 데이터 전송

 

3-1. 비 연결성, 무 상태성

HTTP는 장점이 단점이다.

한번 주고받고 연결을 끊음으로써 자원을 아끼는 대신,

이렇게 매번 새로운 연결을 시도/해제 하는 과정을 거쳐야 하기 때문에 그에 대한 오버헤드가 발생한다.

 

오버헤드 : 어떤 처리를 하기 위해 들어가는 간접적인 처리 시간, 메모리를 말함

 

3-2. 평문 데이터 전송

평문 데이터는 텍스트 기반이라고 보면 된다.

HTTP는 암호화를 하지 않은 평문 데이터를 전송하는 프로토콜이기 때문에, 주민번호나 비밀번호를 주고 받으면 다른 사람이 조회할 수 있다. 이 문제점이 HTTP의 가장 큰 단점으로 이를 해결하기 위해 HTTPS가 나왔다.

 

4. HTTPS란 ?

HTTPS는 HTTP에 데이터 암호화를 추가한 프로토콜이다. 네트워크 상에서 제 3자가 데이터를 조회할 수 없도록 암호화를 지원한다.

암호화는 SSL이라는 보안 계층이 전송계층 위에 올라간다. 

 

4-1. 암호화

HTTPS는 2가지의 대칭키 암호화, 비대칭키 암호화 방식을 지원하고 있다.

 

5. 대칭키 암호화

클라이언트와 서버가 동일한 키를 사용해 암호화/복호화 가능

키를 뺏기면 매우 위험하지만 연산 처리 속도가 빠름

 

5-1. 대칭키 암호화 예시

데이터를 보내는 쪽과 받는 쪽이 데이터를 암호화 하고 복호화 할 수 있는 키를 공유하는 것이다.

 

예를 들어보자. 아래의 임의의 문자열을 키라고 정하자. 이 키는 나와 서버가 가지고 있다.

a084#l%^q3_97 //임의의 문자열

 

그리고 내가 서버한테 비밀번호를 전송한다. 전송할 때, 알고리즘이 내가 입력한 비밀번호와 임의의 문자열을 넣고 돌려 다른 사람이 보면 무슨 말인지 전혀 알 수 없는  암호문이 만들어 진다. 이 암호문을 서버로 전송한다. 

비밀번호(서버로 전송한 데이터)
skatpdnjs

키(임의의 문자열)
a084#l%^q3_97

//대칭키 알고리즘
skatpdnjs + a084#l%^q3_97 = 뛟빭썋줹훃홍

 

암호문을 받은 서버는 똑같은 키와 암호문을 넣고 알고리즘을 거꾸로 돌리면 내가 보낸 비밀번호가 복호화 되는 것이다.

서버가 받은 암호문
뛟빭썋줹훃홍

키(임의의 문자열)
a084#l%^q3_97

//대칭키 알고리즘을 거꾸로 돌림
뛟빭썋줹훃홍 - a084#l%^q3_97 = skatpdnjs

 

서버에선 다시 응답할 데이터를 암호화 시켜 보내는 것이다.

즉, 키를 알 수 없다면 절대로 서버와 보내고 받는 데이터가 무엇인지 알 수 없다.

 

여기서 문제는, 한번은 서버에서 나한테 키를 전송해야 하는데, 이 때 누군가 키를 훔쳐본다면

이후 내가 서버랑 주고받는 메세지가 무엇인지 다 알게 된다.

 

6. 비대칭키 암호화

1개의 쌍으로 이루어진 공개키와 개인키를 사용해 암호화/복호화 가능

키를 뺏겨도 비교적 안전하지만 연산 처리 속도가 느림

 

6-1. 비대칭키 암호화

공개키와 개인키는 서로를 위해 존재하는 것이다.

• 공개키 : 모두에게 공개 가능한 키
• 개인키 : 나만 가지고 알고 있어야 하는 키

암호화를 공개키로 하느냐 개인키로 하느냐에 따라서 얻는 효과가 다르다.

 

 

• 공개키 암호화 : 공개키로 암호화를 하면 개인키로만 복호화할 수 있다. 
• 개인키 암호화 : 개인키로 암호화를 하면 공개키로만 복호화할 수 있다. 

위에서 말했던 SSL은 공개키 암호화 알고리즘을 사용한다.

 

6-2. 암호화 동작방식 예시

비대칭키 암호화의 중요한 점은 공개키로 암호화한 데이터는 개인키로만 복호화할 수 있으며,

개인키로 암호화한 데이터는 공개키로만 복호화할 수 있다는 점이다.

 

서버는 두 키를 모두 가지고 있다. 개인키는 비밀로 보관하고, 공개키는 누구나 볼 수 있도록 뿌린다.

사용자들 : 공개키를 가지고 있음
서버 : 공개키 뿌림, 개인키는 서버 어딘가 비밀로 보관중

 

사용자는 뿌린 공개키로 전송할 데이터를 암호화해서 서버로 보낸다.

예시 : 비밀번호를 입력함
입력한 비밀번호 : skatpdnjs

skatpdnjs + 공개키 = ????? -> 서버

 

만약 누가 이 암호문을 가로챈다면 ? 아마 비대칭키 원리를 알고 있는 사람들은 가로채지 않을 것이다.

자신이 가지고 있는 공개키로는 암호화를 풀어낼 수 없다. 아까도 말했듯이 공개키로 암호화한 암호문은 개인키로만 풀어낼 수 있다.

즉, 대칭키의 문제점을 해결한 것이다.

 

그리고 암호문을 받은 서버는 개인키로 복호화 시켜 다시 개인키로 암호화를 해 사용자에게 보낸다.

????? + 개인키 = skatpdnjs
skatpdnjs + 개인키 = ????? -> 사용자

 

하지만 여기서 문제점이 한가지 더있다.

 

6-3. 또다른 문제점?

예시를 들어보자. 나는 구글 사이트에서 url을 입력했다. 그럼 공개키로 암호화한 url이 서버로 전송할 것이고,

서버는 받아서 복호화 시킨 다음 해당 사이트 페이지를 나한테 보낼 것이다. 근데 만약 이 서버가 사실 구글이 아닌 악용할 목적으로 만들어진 다른 사이트라면 ? 

client --- skatpdnjs.tistory.com ---> 구글인척 하는 사이트

 

그 서버는 내가 보낸 데이터를 보고 응답을 하는 척 하면서 읽는 순간 컴퓨터를 마비시키는 악성코드를 보냈다고 가정하자.

그럼 나는 아무런 의심없이 열어볼 것이고, 내 컴퓨터는 마비가 되는 것이다.

그럼 구글이 구글사이트라는 것을 어떻게 증명할까 ?

 

바로 서버에서 암호화시켜 나한테 보내는 응답메세지에 정답이 있다.

내가 구글창에 skatpdnjs.tistory.com url을 입력을 했다고 가정해보자. 그럼 url은 암호화 되서 보내지고 서버는 받아서 복호화 시키고 해당 사이트 페이지를 응답한다. 악용사이트는 해당 페이지인 척 악성코드를 응답할 것이다.

client -- skatpdnjs.tistory.com --> 구글웹서버
client -- skatpdnjs.tistory.com --> 구글인척하는 악용사이트

8^&$*#%) = 구글웹서버 개인키로 암호화
*(&)*(& = 악성코드

 

이 때 응답메세지 일부는 구글의 개인키로 암호화가 되어있다.

우리가 공개키로 알아볼 수 있는 건 구글의 개인키로 암호화된 데이터 뿐이니까, 이 점을 이용한 것이다.

악용 사이트에서 보낸 데이터는 공개키로 열어보려고 하면 악성코드를 읽기 전에 오류가 날 것이다.

공개키 + 8^&$*#%) = 정상적인 페이지
공개키 + *(&)*(& = 오류 뜸

 

6-4. 또또다른 문제점??

내가 구글에서 skatpdnjs.tistory.com 페이지 넘어가려면 공개키로 암호화해서 보내주면 된는 것은 다 알 것 이다. 이 때, 공개키가 과연 구글에서 뿌린 공개키가 맞을까 ?

한마디로 정품인지 확인이 가능하냐 인 것이다.

 

공개키가 정품인지 확인해주는 민간기업이 있다. Certificate Authority, 줄여서 CA라고 한다.

 

 

아무나 차릴 수 있는 기업이 아니라 엄격한 인증 과정을 거쳐야 CA가 될 수 있다.

우리가 사용하고 있는 브라우저, 즉 크롬이나 사파리, 파이어폭스, 엣지, 익스플로러 등에는 CA들의 목록이 내장되어 있다.

그럼 어떻게 정품인지 확인하는 과정을 알아보자.

 

7. 우리가 크롬에서 구글로 접속할 때 벌어지는 일

크롬에서 구글로 접속하기 전, 접속하려는 사람의 개념을 client라고 한다. 쉽게 사용자라고 생각하면 된다.

클라이언트는 아직 해당 사이트(구글)의 서버를 신뢰하지 못한다.

그래서 이 둘은 일종의 탐색과정을 거치게 된다. 이 과정을 handshake, 악수라고 한다.

 

먼저 클라이언트는 어떠한 랜덤 데이터를 생성해서 구글 웹서버에 보낸다.

client ----- 와라잇 -----> 구글 웹서버

 

랜덤 데이터를 받은 구글 웹서버는 서버측에서 생성한 무작위 데이터와 해당 서버의 인증서를 실어서 보낸다.

client <----- 크라몋, 인증서 ----- 구글 웹서버(와라잇 저장)

 

이 과정이 악수 과정이다. 그럼 클라이언트는 이 인증서가 진짜인지 크롬에 저장된 CA들의 정보를 통해 확인하게 된다.

어떻게 확인하느냐? 이것도 비대칭키 시스템으로 확인한다.

 

7-1. 인증서 진짜/가짜 판별

미리 CA의 인증을 받은 인증서들은 해당 CA의 개인키로 암호화 되어있다.

구글 웹서버에서 보낸 인증서가 진짜라면 크롬에 저장된 CA의 공개키로 웹서버가 보낸 인증서를 복호화시킬 수 있다.

이 공개키로 복호화할 수 있는 인증서를 발급할 수 있는건 그에 대응하는 개인키를 가진 CA뿐이기 때문이다.

 

요약하자면 CA는 인증된 인증서를 웹서버한테 암호화시켜 발급하고, 웹서버는 인증서로 자신이 인증된 사이트인 것을 확인해보라며 보내주는 것이다. 그럼 client는 CA의 공개키로 풀면 인증된 웹사이트이고, 만약 CA 리스트중에 웹사이트가 보낸 인증서에 해당하는 것이 없다면 

아래와 같은 표시가 뜨는 것이다.

 

 

8. 복잡한 과정

만약 인증서가 복호화 되었으면 인증서 안에 공개키가 들어있다. 그래서 이 공개키를 가지고 비대칭키 방식으로 데이터를 보내고 받으면 되나? 반은 맞고 틀리다. 위 과정을 통해 안전한 사이트라는 것이 증명되었으면, 그 후에 데이터를 주고 받을 때는 대칭키 방식과 비대칭키 방식을 섞어서 사용한다. 이유는 간단하다. 데이터를 보내고 받을 때마다 비대칭키 방식을 사용하면 컴퓨터에 큰 부담을 주기 때문이다.

 

8-1. 대칭키는 탈취당할 위험이 있다면서요 ?

아까 악수할 때 사용된 무작위 데이터를 가지고 비대칭키를 이용해서 공유한 다음, 그 다음부터 대칭키 방식으로 데이터를 보내고 받는 것이다. 

 

클라이언트는 악수할 때 받은 두 무작위 데이터를 혼합해서 임시 키를 만든다.

와라잇 + 크라몋 = @#$&%*

 

이 임시키는 인증서에 들어있는 공개키로 암호화해서 서버로 보낸다.

client ----- @#$&%* -----> 서버

 

그리고 어떠한 과정을 거쳐 동일한 대칭키가 만들어진다.

그럼 이 대칭키는 서버와 client, 둘 만 가지고 있으니까 이후 서로 주고받는 메세지들을 제 3자가 알아볼 일은

절대절대절대 없을 것이다.

더 신기한 소리는 이 미친과정을 거치는 HTTPS로도 모든 보안문제가 해결되지 않는다는 것이다.