SSL/TLS

웹 애플리케이션에서 QR Code Scanner 기능을 추가하기 위해 vue-qecode-reader 라이브러리를 사용했는데, 해당 라이브러리는 localhost와 HTTPS 프로토콜에서만 작동을 했다. 이유는 웹 브라우저의 보안 정책 때문인데, 이를 해결하기 위해 TLS 인증서를 적용하게 되었다.

 

HTTPS란

SSL(Secure Sockets Layer) 또는 TLS(Transport Layer Security) 프로토콜을 사용하여 인터넷 상에서 데이터를 안전하게 암호화하여 전송하는 방식이다.

 

HTTPS가 필수인 이유

내가 참고한 라이브러리의 github issue 내용을 살펴보면 MDN(Mozilla Developer Network)에서 제공하는 navigator.mediaDevices가 HTTP 페이지에서 undefined로 처리되기 때문에 getUserMedia 같은 API를 사용하려 할 때 동작하지 않는다. 그래서 이 라이브러리에서 웹 페이지가 HTTPS로 로드되었는지 여부를 체크하고 카메라 기능이 동작하도록 코드가 작성되어 있다고 한다.

https://github.com/gruhn/vue-qrcode-reader/issues/398

camera does not appear / not showing when i deploy the application in server · Issue #398 · gruhn/vue-qrcode-reader

 

SSL/TLS

SSL

SSL(Secure Scokets Layer)은 암호화 기반 인터넷 보안 프로토콜이다. 웹에서 전달되는 모든 데이터를 암호화하고 특정한 유형의 사이버 공격도 차단한다.

 

TLS

SSL의 업데이트 버전으로 SSL의 소유권 변경으로 인해 명칭만 변경된 것이다.

클라이언트와 서버간의 핸드셰이크 인증 방식을 통해 데이터를 검증한다.

 

이를 적용하기 위해서 인증서가 필요하다.

 

작동 방식

웹에서 전송되는 데이터를 암호화한다. 클라이언트와 서버가 통신을 암호화하기 위해 핸드셰이크를 수행한다. 이 과정에서 클라이언트와 서버는 서로의 신원을 인증하고, 암호화에 사용될 키를 교환한다. 

 

Handshake

HTTP 통신은 TCP로 3-way handshake를 통해 연결하여 통신한다. 반면 HTTPS는 HTTP와 TCP 사이에 TLS라는 보안 Layer를 거친 후에 HTTP 통신을 하는 형태이다. 즉, TCP 3-way Handshake 연결이 확립된 후에, TLS Handshake를수행해서 보안 설정을 진행한다.

 

일반적으로 RSA 키 교환 알고리즘이 사용되는데, 해당 알고리즘을 통해 Session Key를 안전하게 교환한다.

대칭키 암호화와 비대칭키 암호화 방식이 모두 사용된다. 비대칭키 암호화를 통해 키를 교환하고, 이후 데이터 전송에는 대칭키 암호화를 사용한다. 비대칭키는 보안성이 뛰어나지만 속도가 느리다. 반대로 대칭키 빠른 데이터 처리가 가능하다.

 

 

TLS 통신 1: ClientHello

• ClientHelloZ
  클라이언트가 서버에게 보내는 첫 메시지이다. 클라이언트가 자신이 생성한 렌덤데이터, 사용가능한 암호화 방식 등을 서버에제 전달한다.

 

TLS 통신 2: ServerHello, Certificate

• ServerHello
  서버는 ClientHello 메시지에 담신 내용을 확인한다. 이 후 클라이언트에게 자신이 생성한 랜덤데이터, 세션 ID와 함께 선택화 암호화 방식을 클라이언트에게 보낸다.

• Certificate
  서버는 클라이언트에게 자신의 인증서를 보내고, 클라이언트는 이를 검증한다.

 

• Server Key Exchange
  인증서 안에 서버의 공개키가 없는 경우 보내는 메시지이다.

• ServerDone
  Certificate를 전송했으면 이 메시지를 클라이언트에게 전송한다.

 

여기까지 완료하면 서로의 신원을 확인할 수 있다. 이제 남은 것은 클라이언트와 서버간의 암호화된 통신을 준비하는 것이다.

 

TLS 통신 3: Client Key Exchange, Change Cipher Spec, Encrypted Handshake message

• Client Key Exchange
  클라이언트는 서버에게 pre-master secret을 전달한다. 클라이언트는 자신의 랜덤 데이터와 인증서에 담겨있던 서버의 랜덤 데이터를 이용하여 pre-master secret를 생성한다.

 

pre-master secret?

서버와 클라이언트는 동일한 pre-master secret로 session key라는 대칭키를 생성해서 데이터 암호화에 사용한다. 따라서 클라이언트의 입장에서 무엇보다 중요한 것은 pre-master secret을 안전하게 전송해내는 것이다. 이를 위해서 pre-master secret을 서버의 공개키로 암호화하는 방법을 사용한다. 그렇다면 서버는 암호화된 것을 자신의 개인키로 복호화함으로서 pre-master secret을 확인할 수 있다. 서버의 공개키는 서버가 보낸 인증서나 Server Key Exchange 메세지에서 확인할 수 있다.

 

• Change Cipher Spec
  handshake에 의해 협상된 암호화 방식을 사용하여 통신한다는 것을 알린다.
• Encryted handshake message(finished)
  handshake가 종료됨을 알린다.

 

이제부터 Application Layer에서 발생한 모든 데이터들이 Session key에 의해 암호화된다.

 

 

인증서

인증서를 통해 웹사이트가 신뢰할 수 있는 사이트라는 것을 보장한다.

해당 인증서를 발급하는 기관은 CA(certificate authority)이다.

인증서는 적용되는 도메인의 개수 및 유효성 검사 수준에 따라 유형이 나뉜다.

 

적용되는 도메인 개수에 따른 유형

• 단일 도메인(single domain) - 단 하나의 도메인에만 적용이 가능한 인증서
• 와인드카드(wildcard) - 단일 도메인 인증서처럼 하나의 도메인에만 적용되지만, 해당 도메인의 하위 도메인도 포함이 된다. 예를 들어 www.example.com, blog.example.com, delvelopoers.example.com 등 을 포함할 수 있다.
• 멀티 도메인(multi domain) - 관련되지 않는 여러 도메인에 적용할 수 있는 인증서

유효성 검사 수준에 따른 유형

• 도메인 유효성 검사(Domain Validation) - 가장 느슨한 수준의 유효성 검사, 기업이 도메인을 관리하고 있다는 것 정도만 증명된다.
• 조직 유효성 검사(Organization Validation) - 인증서 발급 시 CA가 기업을 확인하여 증명(사업자 등록증, 신청자 등)
• 확장 유효성 검사(Extended Validation) - CA는 조직이 존재하고 법적으로 사업자로 등록되어 있는지, 유효한 주소인지 등을 확인한다. 그만큼 시간이 오래 걸리고 비용도 많이 든다. 가장 큰 신뢰를 제공한다.

 

보안 문제가 생겼을 때, 인증서의 유효성 검사 유형이나 상태를 파악하면 원인을 빠르게 찾아 대응할 수 있다.