SSL 인증서 적용 과정에 대한 이해

1. 개요

이번에 프로젝트를 진행하면서 SSL 인증서를 다시 적용해 볼 기회가 있었다.

적용해 보는 과정을 거치면서, 해당 과정에 대한 이해가 부족함을 느끼었고, aws를 사용하는 과정에서 버벅임을 느꼈다.

이에, SSL 인증서와, 비대칭 암호화, RSA 알고리즘 등에 대해 자세히 공부해 보고자 한다.

 

2. 공부 과정

https://john721.tistory.com/35

[AWS] Route53에 외부 도메인(가비아) 연결, SSL 인증서

 

이 분의 블로그에서는, 적용 과정이 어떤 이론을 가지고 일어나는 지에 대한 설명이 잘 되어 있는 것 같다.

따라서, 해당 블로그를 참고하여 공부하였다.

 

SSL 적용 과정에 대한 요약은 다음과 같다.

1. Route53 에 도메인 입력 후, NS 레코드 생성
2. Gabia에 NS 1, 2, 3, 4차 입력
3. ACM(AWS Certificate Manager)에서 CNAME 발급
4. Gabia에 CNAME 작성
5. 로드 밸런서 생성하면서 target group도 생성

 

이런 방식으로, 흐름이 진행되게 된다.

리스너로 80과 443을 열어두고, 80을 443으로 redirection을 통해서, https 를 통한 연결만 가능하도록 한다.

 

이후, 대상그룹에서는 요청을 ec2에서 열어둔 포트로 보내면 된다. 

위 사진에서는 8080 포트로 요청을 보냈다.

 

1. Route53에 도메인 입력 후, NS 레코드 생성

NS 레코드를 제공함으로 인해, 어떤 네임 서버로 요청을 보내야 할 지 알 수 있다.

NS가 많은 이유는, 하나의 NS에 문제가 생기더라도, 다른 NS에서 받아올 수 있도록 하기 위함이다.

 

2. Gabia에 NS 1, 2, 3, 4차 입력

AWS 에서 생성한, NS 리스트를 Gabia에게 일러준다.

 

3. ACM(AWS Certificate Manager)에서 CNAME 발급

CNAME은 도메인 별칭을 정의한다. 

이를 통해 gabia에서 구매한 도메인으로 들어온 요청을, 다른 load balancer나 ec2에 연결시켜줄 수 있다.

 

또한, CNAME레코드는 domain을 가리켜야 하며, IP 주소를 가리켜서는 안된다.

따라서 이를 이용해서 다른 단서가 있는 레코드들을 가리켜줄 수 있다.

 

ACM은 SSL 인증서를 손쉽게 관리 가능하게 한다.

 

4. Gabia에 CNAME 작성

Gabia에서 CNAME을 일러줌으로서, SSL 인증서 관리 등을 용이하게 할 수 있도록 한다.

또한, 인증된 것임을 일러줄 수 있다.

 

5. 로드 밸런서 생성하면서 target group도 생성

로드 밸런서는 SSL Handshake를 진행할 수 있도록 하면, SSL 인증서를 탑재 가능하도록 한다.

 

또한 로드 밸런서를 이용해서 리스너 포트를 설정해 둘 수 있으며, redirection 또한 정의해 줄 수 있다.

대상 그룹으로, ec2 를 가리켜서 포트 연결을 해주면 된다.

만약 8080 포트를 ec2에서 열어두었고, 이를 이용한다면, 대상 그룹으로 해당 ec2의 8080으로 설정해 두면 된다.

 

그렇다면, HTTPS 는 어떤 식으로 작동하게 되는 것일까?

 

HTTPS는 asymmetric encryption (비대칭 키 암호화 방식)을 이용하며, 그 중에서도 RSA 알고리즘을 이용한다. 

RSA는 소수를 이용한 암호화 방식이라고 생각하면 될 것이다.

 

비대칭 키 암호화 방식은 base로 one-way function을 이용한다.

이는 간단히 말하면, 어떤 수를 곱해서 결과 값을 얻는 것은 쉽지만, 결과 값을 가지고 곱해준 수를 구하는 것은 어려운 방식을 이용한다.

따라서, public Key와 private Key를 A 와 B가 주고 받는다면, A가 public Key로 암호화 해서 준 것을 B가 private Key로 복호화 할 수 있는 것이다.

 

다른 Key를 이용하는 주된 이유는, Key를 전달해 주는 과정에서 탈취 당할 수 있기 때문이다.

따라서, 다른 Key를 이용하여, 탈취 당하더라도 복호화하지 못하도록 할 수 있다. 왜냐하면 탈취 당한 것은 private Key가 아닌 public Key일 것이고, 복호화를 위해서는 private Key를 필요로 하기 때문이다.

 

 

SSL HandShake에 대해서 이해를 들어가 보자.

https://aws-hyoh.tistory.com/39

HTTPS 통신과정 쉽게 이해하기 #3(SSL Handshake, 협상)

SSL HandShake에 대한 설명을 실제, Packet을 사진으로 보여주어, 이해가 쏙쏙 되었다.

 

우선, server에서 CA (Certificate Authority)를 이용해서, SSL 인증서를 암호화 해준다.

CA는 일종의 검증된 키 발급 기관..? 이라고 생각하면 좋을 것이다.

 

따라서, 암호화된 SSL 인증서 안에 public Key(Server 발행)를 포함해서 client에게로 넘겨주게 된다.

server는 private key(Server 발행)를 가지고 있을 것이다.

 

암호화된 인증서를 CA에게서 받은 public Key (CA 발행)로 복호화 해주어, client는 public Key (server 발행)을 얻을 수 있도록 한다.

 

다음으로 client 또한, private Key(Client 발행)를 생성해서, server로부터 받은 public Key(server 발행)로 암호화를 해서 server에게 전달을 해주게 된다.

 

다시, server는 자신이 만들었던 private key(server 발행)으로 client가 제공해 준, public Key(client 발행) 를 복호화 해준다.

 

이렇게 client와 server는 public Key를 서로 교환하고, 각자 생성한 private Key를 한 쌍씩 가지게 된다.

 

하지만, asymmetric encryption 방식은 보기와 같이 expensive하기 때문에, symmetric encryption 방식으로 전환하고자 할 것이다.

 

비대칭 키 암호화 방식으로 이미 서로 안전하게 소통할 방법을 지니고 있다.

따라서 이를 이용해서 session key를 client와 server가 서로 주고 받는다.

 

client는 session Key를 생성해서, 이를 public Key(server 발행) 로 암호화 해서 server에게 전달하게 된다.

 

server는 encrypted session key를 제공 받게 되고, 이를 private key(server 발행) 로 복호화 한다.

이로서, client와 server는 모두 동일한 session key를 가지게 되고, 이를 이용해서 symmetric encryption을 이용할 수 있다.

 

https://www.youtube.com/watch?app=desktop&v=j9QmMEWmcfo

 

이 분의 영상을 보며 이해하였다.