HTTPS 적용 및 통신 과정

0_0_yoon·2022년 8월 10일

TLS https ssl

팀 프로젝트에 HTTPS 를 적용한 과정과 HTTPS 통신 과정을 정리했다.
먼저 HTTPS 는 두 가지 방법으로 적용해 봤다.

직접 인증서를 발급 받아 Nginx 에서 설정하기
CloudFlare 를 사용해서 HTTPS 적용하기

1. 직접 인증서를 발급 받아 Nginx 에서 설정하기

필요사항

도메인이 필요하다.(가비아)
ssl 인증서가 필요하다.(Let’s Encrypt)
nginx 에서 https 활성화 설정을 해야한다.(Certbot)

1. 도메인연결

백엔드 main ec2(public ip: 43.200.175.197)
www.f-12.shop, f-12.shop 으로 접속 가능하다.

2. 백엔드 main ec2 에 nginx 설치

sudo apt-get install nginx

3. reverse proxy 설정

cd /etc/nginx/sites-available
sudo vi default

server {
		// 연결한 도메인 입력, 이름은 공백으로 구분함
		server_name f-12.shop www.f-12.shop;

		location / {
				// 연결할 서버 주소 입력
				proxy_pass http://{ backend main ec2의 private ip };
		}
}

파일 수정후 테스트 실행(변경한 파일에 오타가 있으면 테스트를 통과하지 못한다)

sudo nginx -t

nginx 재시작(변경사항 적용)

sudo systemctl restart nginx

4. SSL 인증서 발급

certbot(Let’s Encypt 인증서를 자동으로 사용하여 HTTPS를 활성화해주는 무료 오픈 소스 소프트웨어) 사용

certbot 설치하기

sudo snap install certbot --classic

certbot 으로 Let’s Encypt SSL 인증서 발급(https 활성화 설정)

// -d 를 사용해서 한번에 여러개의 도메인을 등록함
// usage: certbot [SUBCOMMAND] [options] [-d DOMAIN] [-d DOMAIN] ...
sudo certbot --nginx -d f-12.shop -d www.f-12.shop

Certbot 이 자동으로 433 포트 설정을 해줌

Certbot 이 http → https 리다이렉션 설정을 해줌

2. CloudFlare 를 사용해서 HTTPS 적용하기

CloudFlare 를 사용하면 자동으로 Universal SSL 인증서가 발급되고 이를 통해서 Https 설정이 가능했다. 기존에 Https를 적용하기 위해서 각 Ec2 마다 Certbot 을 설치해서 인증서를 다운받아 Nginx 에서 Https 를 설정 했지만 CloudFlare 를 사용하면 한 번에 HTTPS 를 적용할 수 있다는 장점이 있었다.

메인화면에서 Add Site
구입한 도메인 입력
무료 ssl 지원 서비스 선택
가비아 네임서버 수정
가비아에 접속해서 네임서버를 CloudFlare의 네임서버로 수정한다.

수정을 올바르게 마치면 CloudFlare 에서 메일을 보내준다.
HTTPS 설정
1. Automatic HTTPS Rewrites 활성화(자동으로 Http 를 Https 로 변경)
2. Always Use HTTPS 활성화
3. 나머지 옵션은 비활성화
발급된 SSL 인증서 확인

SSL encryption mode

Cloud Flare는 HTTPS 로 요청을 받아서 우리의 AWS EC2 서버의 80번 포트로 패킷을 전달해준다.

HTTPS 통신 과정

HTTPS 는 TCP 위에 SSL/TLS 층을 추가하여 암호화, 인증 그리고 무결성 보장을 통해 더 안전하게 만들어주는 프로토콜이다.
대칭키와 공개키 방식을 전부 사용하는 하이브리드 방식이다. 데이터 전송을 위해 대칭키 방식을 사용하며 대칭키를 안전하게 전달하기 위해 공개키 방식을 사용한다.
먼저 대칭키 방식과 공개키 방식을 알아보자.

대칭키 vs 공개키

대칭키의 경우에는 클라이언트와 서버가 모두 같은 키로 암복호화를 한다. 속도가 빠르다. 하지만 최초에 대칭키를 교환할때 탈취 당하게 되면 암호화 의미가 없어진다. 이를 보완하기 위해서 나온 방법이 공개키 방식이다. 대칭키를 클라이언트에서 공개키로 암호화를 하고 서버에서 개인키로 복호화를 한다. 이런 방식을 공개키 방식이라고 한다. 대칭키에 비해 처리하는 속도가 느리다.

CA

HTTPS 통신을 할때 서버는 SSL 인증서를 클라이언트에 보내줘야 한다. 그렇다면 서버는 어떻게 SSL 인증서를 발급받을 수 있을까?
서버는 도메인을 가져야한다. 도메인 주소와 사이트 정보를 공인인증기관(CA)에 보내면 인증절차를 거친뒤에 안전한 사이트임이 확인되면 CA의 개인키로 암호화된 SSL 인증서를 발급해준다.

HTTPS 통신 과정

HTTPS 통신 과정을 살펴보자. 클라이언트에서 요청을 보내면 HTTPS 는 TCP 기반 프로토콜이기 때문에 3way-handshake 를 한뒤에 SSL handShake 를 진행한다. SSL handShake 과정에서 대칭키를 교환하게 된다.

클라이언트에서 세션아이디, 브라우저가 지원하는 암호화 알고리즘 집합과 TLS 버전, 난수 값(바이트)을 생성해서 요청을 보낸다.
서버에서는 클라이언트 난수 값과 서버에서 생성한 난수 값, SSL 인증서, 사용할 TLS 버전과 암호화 알고리즘을 보내게 된다.
클라이언트의 브라우저에 내장된 CA 공개키로 SSL 인증서를 복호화를 한다. (복호화가 된다면 서버가 안전한 사이트임을 보장받은것) 복호화 후에 SSL 인증서 안에 있던 서버에서 만든 공개키를 얻는다.
응답 받았던 클라이언트 난수 값과 서버에서 생성한 난수 값으로 대칭키를 만든다. 이 대칭키를 공개키로 암호화해서 서버에 전달하게 된다.
서버에서는 개인키로 복호화해서 대칭키를 얻는다.