http https

프론트와 협업을 하면서 백앤드는 익스프레스로 http 환경의 서버를 띄우고

프론트는 버셀?이라는 것을 사용해서 서버를 띄우면 https의 환경이 만들어진다.

 

하지만, 두 서버가 api 통신을 할 경우 http 환경이 달라서 통신을 할 수가 없다.

그렇기 때문에 프론트에서 S3로 http환경을 구축하여 통신하거나

서버에서 https 환경을 만들어 통신해야 한다.

 

백앤드가 배포를 중점으로 하진 않지만, 그래도 프론트보다 배포에 조금 더 관여를 하고 있기 때문에 서버에서 https 환경을 구축하는 게 맞다고 생각한다.

또한 http와 https의 보안 차이도 크기 때문에 보안을 강화해서 통신을 하는 것이 좋을 것 같다.

 

 

http란

기본적으로 클라이언트와 서버 사이에서 데이터를 주고받는 통신 프로토콜이다.

주고받는 데이터가 전송될 때 암호화되지 않기 때문에 보안에 취약하다.

 

https란

하이퍼 텍스트 전송 프로토콜 보안 (HTTPS) 사용하는 HTTP 프로토콜의 보안 버전이다.

SSL(Secure Socket Layer)이라는 프로토콜을 사용해 주고받는 정보를 암호화한다.

 

 

기본적인 암호화 개념

암호화(encryption)는 어떤 정보를 아무나 읽지 못하도록 키를 가지고 특정 알고리즘을 돌려 정보를 숨기는 것을 말한다.

키를 가지고 다시 알고리즘을 역행하면 복호화(decryption)가 된다.

키가 없으면 암호화와 복호화를 하지 못한다.

 

- 공개키 / 비밀키

공개키 : 모두가 볼 수 있는 키

비밀키 : 소유자만이 가지고 있는 키(암/복호화에 사용)

 

- 대칭키 암호화

서버와 클라이언트가 암호화/복호화에 동일한 비밀키를 사용하는 방식

키를 공유하는데 어려움이 있으나 속도가 빠르다.

 

-비대칭키 암호화

서버와 클라이언트가 암호화/복호화에 각각 다른 비밀키를 사용하는 방식

공개키를 통해서 암호화를 하고 비밀키를 통해서 복호화를 한다.

공개키는 공개해도 상관없으니 키 관리에 어려움이 없으나, 속도가 느리다.

 

- 인증기관(Certificate Authority, CA)

클라이언트가 접속을 요청한 서버가 의도한 서버가 맞는지 인증해주는 역할을 하는 보증된 기업들

클라이언트는 서버에 요청을 해서 CA가 발급한 인증서를 받은 뒤 CA의 공개키로 복호화하여 신뢰할 만한 인증서인지 검증한다.

CA의 공개키로 복호화되는 자료는 오직 CA의 비밀키로 암호화한 경우밖에 없기 때문에 복호화되면 신뢰할 만한 것이다.

 

 

SSL 동작 방식

SSL은 대칭키 방식과 비대칭키 방식을 적절히 섞어서 사용하면서 신뢰도를 높인다. 

처음에는 비대칭키를 사용해 대칭키를 공유한 후에 대칭키를 이용해 데이터를 주고받는다.

세션이 종료되면 사용한 대칭키를 폐기하는 방식으로 보안성을 높인다.

1. 클라이언트가 서버에 접속하기 위해 클라이언트가 생성한 랜덤 데이터(1)를 서버에 보낸다.
2. 서버는 클라이언트에게 서버가 생성한 랜덤 데이터(2)와 CA에서 발급받은 인증서를 보낸다. 인증서가 필요한 이유는 서버가 신뢰할 만한 서버인지 확인하기 위함이다.
3. 클라이언트는 그 인증서를 받아 CA의 공개키로 복호화한다. 인증서를 복호화하면 접속하려는 사이트의 정보와 사이트의 공개키가 들어있다.
4. 랜덤 데이터 1과 랜덤 데이터 2를 조합하여 대칭키로 사용할 것인데 이는 탈취당하면 안 되기 때문에 인증서에 들어있던 공개키로 암호화하여 서버에 전송한다.
5. 서버는 가지고 있는 비밀키를 이용해 복호화하여 클라이언트가 보낸 대칭키를 얻는다.
6. 이후 그 대칭키를 통해 데이터를 주고받는다.
7. 세션이 종료되면 대칭키를 폐기한다.

 

 

 

HTTPS란?