HTTPS를 왜 써야하는지, 암호화가 뭔지 모른다면 클릭

웹을 운영한다면 https 를 사용하는 것이 너무나 자연스럽다.

http 로 접속하게 되면 '안전하지 않음' 이 뜬다.
인증서를 발급받고 https 설정을 하면된다
이것은 영리한 초딩들도 할 수 있다.
 
https 라는게 뭐지? 인증서는 왜 발급받지?
애초에 http가 뭐지?
 
라는 물음에서 책을 파고파고들며 알게된 지식이다
 
 
 
"HTTPS 는 HTTP 요청과 응답을 SSL/TLS 로 암호화하여 보안을 강화한 HTTP 보안 버젼이다. HTTPS를 사용하려면 SSL/TLS 인증서가 필요하며 이 인증서는 서버가 신뢰할 수 있는 서버임을 보증한다"
 
 
 
쫄지말자!
우선 당신이 쫄았다면 그 이유는 배경지식이 없기 때문이다.
 
HTTPS 에서 핵심 키워드는 보안, SSL, 인증서이다.
 
이 글을 한 번 읽게 되면 다음 질문에 대해 대충 얼버무리며 대답은 할 줄 알게 된다.
 
"HTTPS 가 뭔데?"
"HTTPS 쓰면 뭐가 좋은데?"
 
이 글에서 배경지식을 쌓은 후 본격적으로 인증서, SSL 통신 그리고 이것이 어떻게 보안적으로 유리한지에 대해서 글 말미에 있는 링크를 통해 딥다이브하길 바란다.
 
근데 사실 나는 애매하게 아는걸 싫어하는 성격이어서 집요하게 파고드는 것이고
시간 없다면 이 글만 보고 그냥 돌아가서 https 설정하는 법만 배워서 써도 된다.
 
(https 가 이래서 좋구나~ 하고만 가도 프로젝트 하는덴 문제없다)
 
 
 
https://biz-ninza.tistory.com/15

HTTP란 무엇인고

(우선 HTTP 에 대해서 개념이 잘 안잡혀있다면 제가 작성한 위의 글을 먼저 읽길 권장드립니다)
 
 
 
목차
1. HTTPS란
2. 암호화란
3. 인증방식으로 살펴보는 HTTPS 필요성
4. 인증서가 왜 필요하지 
5. HTTPS는 SSL 위에서 이렇게 동작한다.
 
 
 

1. HTTPS란

 
HTTP (Hypertext Transfer Protocol) 는 Hypertext 즉 HTML 을 전송하기 위한 통신규약.
HTTPS 에서 S는 Over Secure Socket Layer 의 약자로 보안장치가 좀 더 결합된 통신방식.
 
HTTP 전송시 제3자가 감시, 도청, 조작하거나 (도메인을 자신의 것처럼 속이거나?) 하는 일을 막기 위해 좀 더 암호화한다.
 

밑으로 내려갈수록 포괄적인 것이다

 
HTTP가 SSL 프로토콜 위에서 동작하면 HTTPS가 되는 것
그리고 SSL 은 TCP/IP 프로토콜 위에서 동작한다.
TCP 세션을 암호화하고 그 위에 HTTP 요청/응답을 올려서 보안된 통신을 제공하는 것이 HTTPS 프로토콜이다.
 
(한편 SSL과 TLS는 같은 것. 넷스케이프에서 발명된 것인데 TLS이라는 이름으로 바뀜)
 
다시말해 HTTPS 도 결국 HTTP다.
HTTPS는 데이터를 암호화해서 서버와 클라이언트 간 통신을 안전하게 만들는 기술
 
 
 

2. 암호화란

 
https 소개하는데 암호화를 먼저 얘기하는 이유는 이걸 이해하지못하면 JWT 를 쓰는데 왜 HTTPS 를 쓰는지 이해할 수도 없고 인증서의 개념도 이해할 수 없기 때문이다.
 
암호는 그냥 간단하게 글자들을 대체하거나 순서바꿔서 원래내용을 알아보지 못하게 알지못하게 하는 것이다.
다만 이 과정에서 알고리즘이나 암호화 기계가 외부에 공개되어버리면 아무 쓸모가 없다.
 
그래서 대부분 암호 매개변수 '키' 를 이용한다.
인코딩을 할 때도 키가 있어야하고 이를 복호화할 때도 키가 필요하다.
오늘날 대부분 암호 알고리즘은 키를 사용한다.
 

• 대칭키

다시 복습하면, 암호화란 평문을 알아보기 힘든 형태로 만드는 것, 복호화란 이를 기존 평문으로 돌리는 것.
그리고 암호화/복호화할 때 ‘기준이 되는 데이터’ 를 KEY 라고 한다.
KEY 가 있어야 암호화 복호화가 가능하다.
 
이렇게 양쪽이 같은 KEY를 가지고 서로 암호화 복호화한다는 의미에서 이를 대칭키라고함
대칭키는 클라이언트와 서버가 동일한 대칭키를 가지고 있어야하므로 키 관리가 까다롭다.
 

• 비대칭키 (공개키/비밀키)

A KEY로 암호화를 하면 B KEY로 복호화 할 수 있고, B KEY로 암호화하면 A KEY로 복호화할 수 있다.
암호화, 복호화해 사용되는 키의 용도를 다르게 두는 것, 이것을 비대칭키라고 부른다.
 
둘 중에 하나의 키만 관리하면서 반대편 키를 오픈해놓으면 키 하나를 건네는 과정에서 그것이 탈취되어도 상관없고 여러 당사자와 관계를 맺어도 대칭키처럼 여러개를 관리하는게 아니라 나는 키 하나만 잘 관리하면 된다
 
 
 
아래의 내용을 통해 대칭키와 비대칭키를 조금 더 자세하게 이해해보자
 
(아래의 내용을 이해하는데 나는 12시간은 걸린 것 같다. 바로 이해가 된다면 당신은 나보다 지능이 높은 것이니 도전해보자)
 
심호흡 한 번 하고 읽어보자!!  
 
 
 
[암호화]

기본적으로 대칭키에서 공개키는 암호화, 비밀키는 복호화를 위해 사용된다.
즉 공개키를 가진 사람이 자신의 것을 암호화하여 전송하면, 비밀키를 가진 사람은 복호화할 수 있다.
 
공개키는 누구나 가져도된다. 누구나 암호화해서 메세지를 보낼 수 있다. 
하지만 그 정보를 복호화하는데 필요한 비밀키는 나만 알고 있어야 된다. 즉 나는 비밀키 하나만 관리하면 된다.
 
예를 들어보자.
 
온라인 뱅킹을 사용할 때 나는 '은행이 나한테 준 공개키' 로 거래정보를 '암호화' 한다.
은행에 접속하면 은행은 '은행이 가지고 있던 비밀키' 로 거래정보를 복호화하여 거래를 처리한다.
(암호화된 거래정보를 누군가가 중간에서 훔쳐도 비밀키는 은행만 가지고 있으므로 확인이 불가능)
 
⭐️
만약 비대칭키를 썼다고 생각해보자.
 
은행이 만약 모든 고객과 하나의 대칭키로 통신을 한다면 고객 중 한 명만 비대칭키를 빼앗겨도, 해커가 다른 고객들의 거래정보를 탈취하면 모두 복호화가 가능하다. 따라서 비대칭키를 고객 수만큼 배정해서 관리해야한다.
 
그렇게 하면 고객 한 명이 비대칭키를 잃어버려도 다른 고객은 영향을 안받는다.
그러나 키를 빼앗긴 고객은 해커에게 자신의 정보를 탈취당했을 때 이를 계속 해독당할 가능성이 있다.
여전히 한 명이 계속 위험하다.
 
이 때 공개키-비밀키를 쓰게 되면 고객들이 공개키를 통해 자신의 정보를 암호화하여 보낸다. 
은행은 비밀키 하나만들고 이를 복호화하면 된다. (비밀키 하나만 관리한다)
게다가 공개키는 말그대로 암호화할 때만 사용되는 '공개된 키' 라서 해커가 뺏어도 암호화된 정보를 해독할 수 없다.
 
결론적으로 비대칭키를 썼을때 발생가능한 많은 키 관리 문제 + 빼았겼을 때 위협이 모두 해결된다.
 
 
 
[서명]
 
이제는 암호화된 데이터는 은행만 볼 수 있으므로 해커가 통신과정에서 암호화된 데이터를 탈취했다해도 해독할 방법이 전혀없다.
그런데 고객이 바보같이 외부에 비밀정보 (예를들면 카드번호 / 비밀번호)를 오픈해버렸고 악의적인 제 3자가 이를 공개키로 암호화하여 보내면 은행입장에선 이게 진짜 고객인지 타인인지 알 수가 없다.
 
즉 이 데이터를 보낸 사람이 본인이 맞는지 확인하는 절차도 필요하다.
이 과정을 '서명' 한다고 한다. 
 
서명이란 문서나 메세지가 특정 사람에 의해 작성된게 진짜 맞는지를 확인하는 과정이다.
비밀키를 가진 사람이 자신의 것을 암호화하여 전송하면 공개키를 가진 누구나 이 정보를 오픈할 수 있다.
 
가령 A가 B에게 계약서를 보낼 때 A는 계약서에 자신의 사인을 한다.
A가 비밀키로 계약서를 서명하면 B는 'A의 공개키' 로 복호화하여 계약서가 진짜인지 검증할 수 있다. 
(계약서가 진짜가 아니라면 A의 공개키로 복호화가 불가능할 것이다)
 
다시 은행예시로 돌아가보자.
은행이 나에게 비밀키를 발급했고 은행에게 거래정보를 보낼때 '비밀키로 서명'을 하게끔했다면 공개키를 들고 있는 은행은 이 사람이 비밀키를 들고 있구나, 즉 본인이 맞구나 확인이 가능하다,
 
내가 바보같이 외부에 비밀정보를 오픈했어도 비밀키를 잘 들고만 있다면 해커는 내 비밀정보를 알아도 나인척 요청은 할 수 없다.
(물론 비밀정보에 비밀키 마저 뺏겨버리면 답 없다. 그정도면 사실상 그냥 관리를 포기한 것 아닐까)
 
 
여하튼 이런 것을 전자서명이라고 부른다.
곧 이것이 인증서의 원리이기도 하다.

공개키를 가지고는 누구나 암호화할 수 있지만 비밀키를 가지고 암호화한다면 암호화할 수 있는 사람은 자기자신 뿐이므로 서명이 되는 것 (암호화든 복호화든 비밀키를 가진다는 것은 '본인만' 할 수 있음을 의미한다)
 

여하튼 비밀키로 암호화된 데이터는 대응되는 공개키로만 복호화할 수 있으므로 비밀키를 가진자는 '서명자' 가 되고 공개키를 가진자는 '검증자' 가 된다.

신뢰할 수 있는 기관(서명자)의 비밀키로 인증서에 서명을 하고 브라우저(검증자)는 신뢰할 수 있는 기관에게 미리 받은 공개키를 내장한다. 
 
그렇게 하면 클라이언트가 브라우저를 통해 서버에 접속할 때 서버는 인증서ㅡ신뢰할 수 있는 기관의 서명이 있음ㅡ를 브라우저에게 전달한다. 브라우저는 인증서를 받고 내장된 공개키를 사용하여 인증서가 진짜인지를 검증한다. 
 
즉 이 서버가 '신뢰할 수 있는 기관의 인증을 받은 진짜 서버' 임을 확인하는 것이다
 
 
(인증서에는 서명뿐 아니라 서버의 공개키를 포함하고 있는데 이 이유를 자세히 알고 싶다면 이 글 최하단에 첨부된 링크를 통해 HTTPS 통신을공부하시길 바람)
 
 
 
 
* 암호화 + 서명을 동시에 사용하는 예시
 
AWS EC2 서버를 운영해본 경험이 있다면 항상 EC2 인스턴스에서 RSA 로 만든 .pem 을 받는데 이것은 비밀키다.
내가 서버에 연결을 요청하면, 서버는 내장되어있는 공개키로 암호화된 어떤 요청을 보낸다.
나는 비밀키를 가지고 있으므로 복호화하여 그에 맞는 응답을 전송한다.
 
응답을 전송할 때 비밀키로 '서명' 을 하고 서버는 공개키로 이 응답이 진짜 내가 보낸 것임을 검증한다.
즉 클라이언트가 진짜인지까지를 아는 것.
 
 


 
 
이제 JWT와 인증서를 이해할 준비가 되었다!
3,4 챕터를 통해 이 두가지 과정을 음미해보자.
 
 
 

3. 인증방식으로 살펴보는 HTTPS 필요성

 
HTTP 는 stateless 하다.
그러나 여러가지 이유에서 접속자를 식별하는 과정이 반드시 필요하다.
 
요즘엔  JWT나 OAuth2.0 같이 인증 토큰을 주고 받는 Bearer 방식이 주류를 이루는듯하다.
Bearer 는 소유자라는 의미로 토큰을 소유한 사람이 요청을 보내서 좀 더 RESTful 한 설계철학에 맞는 인증방식이라고 할 수 있겠다.

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

 
(HTTP 제어 헤더에 토큰을 보내는 모습)
 
서버가 별도의 세션서버를 유지하지 않아도 되고 분산환경에서 특히나 유리하다 (서버별 세션동기화 작업 필요없으니)
JWT 의 Header, Payload, Signature 구조에서 Header 에 사용된 암호화 알고리즘 을넣고 Claims 에 Key-value 형식으로 roles, permissions 등 원하는 정보를 넣기때문에 확장성이 좋다.
 
그래서 인기가 있다.
 
굳이 자세하게 언급한 이유는 여기에 암호화 알고리즘이 들어갔다는 것을 강조하기 위함이다.
보통 우리가 인증인가에서 사용하는 JWT 는 서명을 암호화한다.
 
 
정신을 집중해서 읽어보자.
 
 
서버가 비밀키를 들고선 헤더와  페이로드에 서명한다 (서버 : "이건 내가발급한 JWT임을 인증하노라")
클라이언트는 JWT 를 받고 파싱해서 내용을 확인한다 
클라이언트가 다시 서버에 요청을 보내면 서버는 공개키를 들고선 서명의 유효성을 검증한다 (서버 : "아 검증되는거보니 내가 인증한 JWT 맞구나")
 
*이 때 서버는 인증한 서버 자신이 될 수도 있고 MSA 같은 구조에서는 JWT 검증이 필요한 다른 서비스가 될 수도 있다. 혹은 OAuth 2.0 같은 경우에는 인증서버가 서명하고 공개키를 외부에 공개해서 다른 서버들이 필요한 경우 검증만 하도록 한다. 예를 들면 소셜로그인을 구현한다면 구글이 비밀키로 서명된 JWT 를 생성하고 우리가 개발한 서버에선 공개키로 이 JWT의 서명을 검증한다.
 
JWT는 Base64로 인코딩 되어있으니 디코딩하면 누구나 내용을 볼 수 있다.
다시말해 JWT 는 암호화되어 있지 않다. 누구나 볼 수 있는 구조다.
다만, 서명 자체는 비밀키를 가진 서버만 할 수 있으니 JWT가 진짜임을 보증할 뿐이다.
 
물론 JWT 자체를 통째로 비밀키로 암호화해서 아무나 보지 못하게 할 수도 있다.
이를 암호화된 JWT라고 한다.
다만 이렇게 매번 통신하는데 암호화/복호화 과정을 거치면 성능이 떨어진다.
그래서 인증인가방식에서는 그냥 서명된 JWT를 쓴다.
 
여하튼 결론은 이거다.
 
"HTTP로 클라이언트와 서버가 통신을 할 때 JWT가 노출되면 그냥 내용을 전체공개하게된다"
"HTTPS 로 통신과정을 가려버리면 JWT 를 숨길 수 있다. 즉 보호할 수 있다"
 
 
 
한편, 예전 Bearer 이전 Basic 이나 Digest 인증에서는 다음과 같은 방식을 거쳤다.
 
먼저 클라이언트가 비밀(?) 페이지에 접근한다.

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="example"

 
그러면 서버가 위와같이 권한없다는 401 상태코드를 주면서 WWW-authenticate 라는 제어헤더에 인증방식을 요구한다.
(Basic 이라는 인증방식을 요구하고 있다. 이 때 인증방식은 Bearer, OAuth, Digest 어떤 것도 될 수 있다)

Authorization: Basic dXNlcjpwYXNzd29yZA

 
그러면 클라이언트는 위와같이 Authorization 헤더에 인증방식으로 비밀번호를 전송한다 
(dxNlc~ 이 값이 password 를 Base64로 인코딩된 평문 비밀번호다)
 
매우 위험하다!
"HTTPS 로 통신과정을 가려야 클라이언트가 보내는 비밀번호를 숨길 수 있다. 즉 보호할 수 있다"
 
 
 
초기엔 위와같은 비밀번호 평문 전송문제를 해결하기위해서 Digest 인증이라고, 서버가 클라이언트에게 nounce 라는 임시문자열을 제공하면 클라이언트가 사용자,비밀번호,nounce 등을 조합해 해시를 생성후 응답하여 서버가 이를 통해 다시 해시를 계산하는 방식을 사용했는데
 
일단 말만 들어봐도 복잡하고 이렇게 구현해봐야 nounce 가 노출되면 공격가능성이 있다.
즉 Digest 방식도 HTTPS 를 써야한다.
 
 
 
정리하면, 예전 HTTP 표준 인증 방식이었던 Basic 혹은 Digest 방식의 인증방식에서는 HTTPS 를 쓰지 않으면 너무 치명적이었다. 
 
요새는 Bearer 를 쓰면서 서버에게 인증방식을 별도로 받아야할 필요가 없으니 www-authentication 헤더는 잘 보지못하게 되었고, 또 Basic 로그인에서 페이지마다 인증방식을 협상하고 인증하거나 혹은 세션관리를 별도로 하지 않아도 된다. 
 
여하튼 여러모로 HTTP 표준 인증 방식은 인기를 잃었고 Bearer 방식, 즉 인증토큰 방식을 많이들 사용하지만 그렇다해도 이를 HTTPS로 가리는 작업이 필요하다는 얘기를 하고 싶었다

 
 
 
https://biz-ninza.tistory.com/8

3장. 서버와 클라이언트는 JWT 토큰을 어떤 방식으로 주고 받게 할까?

 (추가자료1)
HTTPS 로 통신데이터  가려도 피싱사이트를 막을 수 없다. 보안적 관점에서 JWT 를 위의 글처럼 Authorization 헤더로 보낼지, 쿠키로 보낼지에 대한 고민을 하였는데 위의 글이 참고가 되길 바란다.  
 
 
 
https://biz-ninza.tistory.com/20

7장. 도메인에 HTTPS 설정해야지. 인증서는 어디서? - 작성중

 

(추가자료2)
본격적으로 인증서가 뭔지 HTTPS 가 SSL 위에서 어떻게 통신을 하는지에 대한 글