HTTPS통신과 인증서 발급

HTTPS

• HTTP Secure로 HTTP Protocol의 암호화된 버전이다.
• 서버와 클라이언트의 데이터를 전송할 때 암호화를 하여 보안을 유지
• HTTPS는 직접 TCP통신을 하지않고 SSL(TLS)을 사용하여 서버와 클라이언트간의 정보를 암호화한다.
• SSL을 통해 통신상 암호화를 적용하고 인증서를 통해 정단한 페이지를 확인하는 절차를 추가한다.

⇒ 데이터를 암호화하고 사이트를 인증함에 따라서 사이트에 대한 신뢰도를 높일 수 있고, 개인의 민감한 정보를 암호화하여 중간에 탈취가 불가능하므로 모든 것을 온라인으로 진행되는 요즘 필수적이라 할 수 있다.

HTTPS 적용여부 확인

• URL에 HTTPS확인 및 자물쇠 그림확인

어떻게 HTTPS 적용?

실제로는 인증기관 CA를 통해서 발급받는 것이 안전하다. 하지만, openssl을 사용해서 자체인증서를 발급받아서 서버에 적용을 할 수도 있다. 전체적인 흐름을 알기 위해 자체인증서 발급과정으로 설명하겠다.

1. openssl.exe 실행한다.
2. 개인키를 생성한다(private.key)
   ➡️ openssl genrsa -des3 -out server.key 2048
3. CSR 파일 생성한다
   ➡️openssl req -new -key server.key -out server.csr
   → CSR은 인증서 발급을 위해 필요한 정보를 담고있는 인증서 신청형식 데이터이다.
   → 도메인과 IP를 반드시 넣어주어야한다.
4. CRT파일을 생성한다.
   ➡️openssl x509 -req -days 3650 -in server.csr -signkey server.key -out server.crt
   → crt + key = pem 파일이 만들어진다.
   → 이는 서버에서 원하는 형식에 맞춰 pem파일 하나로만 쓸 수도 있고, crt와 key로 분리하여 사용할 수도 있다.
5. 서버에 알맞게 적용한다.
   → 톰캣이나 nginx 다양한 웹서버들은 설정값을 바꾸어준다.
   → 자체 서버들은 openssl 라이브러리를 사용하여 인증서와 키를 등록하는 코드 SSL통신을 구현하는 코드를 직접 구현한다.

HTTPS의 통신과정(WSS)

인증서에 발급한 후 서버와 클라이언트간의 실제 어떻게 암호화 하여 통신할까요?🧐

wss://domain.co.kr:port 요청과 https://domain.co.kr의 차이를 아시나요?

HTTP와 WS의 관계처럼 WSS는 HTTPS기반으로 하지만 HTTPS와 전혀다른 프로토콜입니다. 웹소켓 연결하는 과정에서 3-way Handshake가 끝나면 HTTPS를 WSS프로토콜로 변경하는 protocal switching 과정을 진행합니다.

따라서 웹소켓을 호출할 때는 wss://domain.co.kr:port를 사용하고 처음에 url로 페이지를 들어갈때는 https://domain.co.kr:port로 들어가는 것입니다.

여기까지는 암호화 협상(SSL HandShake)에 앞서서 연결을 생성하기 위해 실시하는 것입니다.

🤩 TCP 3-way Handshake → TLS handShake🤩

기본적인 통신과정을 알았다면 실제 SSL의 통신과정을 살펴보자!

1. 클라이언트 측에서 https://domain.co.kr 요청을 보낸다. (해당 url로 접속한다)
2. 도메인과 연결된 웹서버에서 인증서 정보와 공개키 정보를 담아서 클라이언트에게 전달한다.
3. 정보를 받은 클라이언트는 CA의 개인키로 SSL인증서를 CA의 공개키를 사용하여 복호화 합니다. 이때 복호화가 성공하면 이인증서는 진짜임을 증명할 수 있습니다.
4. 클라이언트는 대칭키(비밀키)를 생성한 후에 SSL의 서버가 발생한 공개키를 이용해 암호화하여 Server에게 전송합니다.(어떤 알고리즘인즘인지 확인가능)
5. Clinet가 Server공개키를 확보하는 과정을 거칩니다.
   (SSL인증서에 내부에 공개키가 있는경우, 없는경우 과정이 다르다.)
6. 클라이언트는 대칭키(비밀키-실제 데이터 복호화) 생성하여 SSL인증서 내부에서 추출한 공개키를 통해 암호화한 후 Server에 전달합니다.
   (이 때, 대칭키는 SSL handshake의 목적이자 이제 데이터를 암호화할 비밀키입니다.)
7. Server, Client 서로에게 Finished Packet을 통해 SSL handshake종료

실제 적용하면서 겪는 문제점들