1st Meet - Https

Daily Object

    - https 를 학습하고 정리한다. 시간이 남으면 http -> https 로 바꿔주는 방법을 알아본다.

Review

    - HTTPS 의 작동 원리를 알게되었다. https 서버를 구축하려면 어떤 과정을 거쳐야하는지 알게되었다.

 

HTTPS 의 등장

HyperText Transfer Protocol Secure

HTTPS는 통신의 인증과 암호화를 위해 넷스케이프가 개발한 넷스케이프 웹 프로토콜이며 전자 상거래에서 널리 쓰이다가, 

구글의 https 가산점 정책으로 대다수의 사이트가 https로 이전하고 있다.

또한 구글이 작년에 배포한 크롬 88 버전부터는 http 에서 다운로드가 불가능하게 하였다.

 

 

왜 https 로 전환하는 걸까?

기밀성 -> 통신에 참여하는 두 참여자의 정보를 보호

무결성 -> http는 웹사이트를 변조하여 전송이 가능했지만 https는 변조를 할 수 없다.

인증    -> 웹사이트의 진위 여부를 확인하며 신뢰성을 검증해준다.

 

 

그럼 https가 좋기만 한가요?

그렇지 않다.

 

기밀성, 무결성, 인증을 제공하는 만큼 서버와 클라이언트 모두 암복호화가 필요하기 때문에 http 보다 리소스를 많이 잡아먹고

http 보다 2 ~ 100 배 정도 느리다고 한다.  모든 정보를 암호화 처리할 필요가 없는 경우 http를 사용하고 암호화가 필요한 것만 처리하는 방법도 있다.

 

또한 CA에 자신의 인증서를 등록하고 유지하는데 돈이 일반적으로 년간 수십만원이 들기 때문에 유지비의 측면에서도 부담이 된다.

 

 

동작원리

 

통신암호화

 

HTTPS는 인터넷 상에서 데이터를 암호화하는 SSL( Secure Socket Layer )프로토콜을 이용하여 해커에게 중간 데이터를 탈취당해도 읽을 수 없도록 하는 것이다.

 

HTTPS의 암호화 방식은 공개키 방식이다.

 

 

신뢰할 수 있는 사이트 검증 절차는 오른쪽 절차와 유사하다.

 

서버(성인)는 CA(동사무소)에 자신의 공개키(지문 정보)를 주고 인증서(주민등록증)을 발급받는다. 클라이언트(술집)은 서버의 인증서를 의심하여 CA에 검증 요청을 하고 검증이 완료되면 서버와 클라이언트의 핸드쉐이크가 시작된다.

 

 

공개키 ? 

공개키는 비대칭키 암호방식에서 생성된다.

비대칭키는 공개키 & 개인키 쌍을 의미하고 공개키로 암호화하면 개인키로 복호화할 수 있다.

공개키는 이름 그대로 공개되어도 상관없는 키이고, 개인키는 절대로 유출되면 안되는 키이다.

 

HTTPS에서 송신자는 수신자의 공개키를 통해 평문을 암호화하고, 수신자는 자신의 개인키를 통해 암호문을 복호화한다.

인터넷 상에서 데이터를 탈취당해도 암호화된 데이터라 수신자의 개인 키 없이는 해독이 불가능하다.

 

어떻게 상대방의 공개키를 가져올까?

 

HTTPS 통신 흐름에 대해서 자세히 들여다보면 알 수 있다.

일단 공개키 저장소라고 부르던 곳이 원래 명칭은 CA(Certificate Authority)다.

신뢰성이 검증된 기업만 CA를 운영할 수 있다. 한국 CA는 KISA가 운영 중.

 

1. 먼저 애플리케이션 서버(A)를 만드는 기업은 HTTPS를 적용하기 위해서 공개키와 개인키를 만든다.

 

2. 그 다음에 신뢰할 수 있는 CA 기업을 선택하고 그 기업에 내 공개키를 관리해달라고 계약하고 돈을 지불한다.

 

3. 계약을 완료한 CA 기업은 또 CA 기업만의 공개키와 개인키가 있다.

CA 기업은 CA기업의 이름과 A서버의 공개키, 공개키의 암호화 방법 등의 정보를 담은 인증서를 만들고, 해당 인증서를 CA 기업의 개인키로 암호화해서 A서버에게 제공한다.

 

4. A서버는 암호화된 인증서를 갖게 된다. 이제 A서버는 A서버의 공개키로 암호화된 HTTPS 요청이 아닌 요청(Request)이 오면 이 암호화된 인증서를 클라이언트에게 준다.

 

5. 이제 클라이언트 입장에서, 예를 들어 A서버로 index.html 파일을 달라고 요청했다면 HTTPS 요청이 아니기 때문에 CA기업이 A서버의 정보를 CA 기업의 개인키로 암호화한 인증서를 받게된다.

 

6. 신뢰할 수 있는 CA 기업의 공개키는 브라우저가 알고 있다.

 

7. 브라우저가 CA 기업 리스트를 쭉 탐색하면서 인증서에 적혀있는 CA기업 이름이 같으면 해당 CA기업의 공개키를 이미 알고 있는 브라우저는 해독할 수 있다. 결국 A서버의 공개키를 얻을 수 있다.

 

8. A서버와 통신할 때는 A서버의 공개키로 암호화해서 Request를 날리게 된다.

 

그럼 A서버에서 클라이언트에게 Response를 보낼 땐 ? 

   -> Request에 자신의 공개키를 포함해 보낼 수도 있고 다양한 암호화 방식이 있다.

 

HTTPS 인증 절차

간략하게 아래 3단계로 나눌 수 있는데 자세한 내용은 참조 <<

1. 개인 키와 공개 키 쌍을 만들고 조직과 공개 키에 관한 정보를 포함하는 CSR( Certificate Signing Request )을 준비한다.
2. 인증 기관에 연결해 CSR 기반 HTTPS 인증서를 요청한다.
3. 서명된 HTTPS 인증서를 획득하고 웹 서버에 인증서를 설치한다.
4. 웹 서버에 http 요청을 https 로 리다이렉션 처리를 해주면 완성