HTTPS와 SSL 인증서

HTTPS VS HTTP

• HTTP는 Hypertext Transfer Protocol의 약자다. 즉 Hypertext 인 HTML을 전송하기 위한 통신규약을 의미한다.
  • HTTP는 암호화되지 않은 방법으로 데이터를 전송하기 때문에 서버와 클라이언트가 주고 받는 메시지를 조작하는 것이 쉽다.
• HTTPS에서 마지막의 S는 Over Secure Socket Layer의 약자로 Secure라는 말을 통해서 알 수 있듯이 보안이 강화된 HTTP 이다.

HTTPS와 SSL

• 웹이 인터넷 위에서 돌아가는 서비스 중의 하나인 것처럼 HTTPS도 SSL 프로토콜 위에서 돌아가는 프로토콜이다.

SSL과 TLS

• 같은 말이다. 하지만 TLS라는 이름보다 SSL이라는 이름이 훨씬 많이 사용되고 있다.

SSL 디지털 인증서

• SSL 인증서는 클라이언트와 서버간의 통신을 제3자가 보증해주는 전자화된 문서다.
• 클라이언트가 서버에 접속한 직후에 서버는 클라이언트에게 이 인증서 정보를 전달한다.
• 클라이언트는 이 인증서 정보가 신뢰할 수 있는 것인지를 검증 한 후에 다음 절차를 수행하게 된다.

CA

• 보증해주는 기관들이 존재하고, 기관들의 리스트는 브라우저에 탑재되어있다.
• 인증서라고 하는 것은 결국 클라이언트와 서버가 서로 신뢰할 수 없기 때문에 중간에서 권위가 있는 기관이 필요하다.

사설 인증기관

• 직접 사용하는 개발 서버의 경우 굳이 인증서를 구입할 필요가 없다. 도메인이 그 사이트라는 것을 인지할 수 있기 때문이다. 그런 경우에 그 사이트에 대한 신뢰성은 이미 확보가 되어있는 상태에서 직접 자신이 CA 역할을 하면서 SSL을 사용하는 방법이 있다. 그 방법을 사용하면 비용도 들지 않고 SSL을 사용할 수 있다. 하지만 공인된 인증서가 아니기 때문에 퍼블릭한, 사적인 서비스가 아닌 곳에서는 사용하면 안된다. 사용자에게 좋지 않은 경험을 준다.

• SSL을 제공하고 있긴 하지만 공인된 기간이 아님을 표시해준다. (빨간색으로 표시)

SSL 인증서의 내용

• google.com 이라는 사이트, 서비스는 GTS CA 라는 곳을 통해 인증이 되었고 GTS CA 는 Google Trust Services - GobalSign Root 라는 루트 인증 기관에 의해서 인증이 되었다는 것을 나타낸다.
• 인증서 자세히 보기에서는 얼마나 유효한지 확인할 수도 있다.

• 클라이언트가 접속했을 때 서버는 자신이 가지고 있는 인증서를 클라이언트에게 전송을 해주는데, 그럼 그 인증서는 어떻게 만들까? 공인된 기관, CA에 의뢰해서 구입하게 된다. 그때 사이트가 어떤 사이트고, 높은 수준의 보안을 요구할 시 여러 서류들을 보내게 될 것이다. 보내는 과정에서 서버는 자기가 생성한 공개키를 같이 인증기관에 보내게 된다. 이 공개키가 언제 사용될지는 나중에 ....

• 자신은 비밀키를 갖고 있고, 자신의 공개키를 만들어서 공개키와, 자신의 서비스에 대한 정보를 묶어 인증기관에게 전송을 하면 그 인증기간은 그것을 심의해서 그것이 문제가 없다라고 판단되면 인증서를 그 서비스에게 제공을 한다.

• 그럼 그 서비스는 앞으로 그 사이트를 접속하는 사용자들에게 인증서를 제공함으로 SSL 이라는 기능을 사용할 수 있게 됨.

CA를 브라우저는 알고 있다

• 브라우저가 미리 파악하고 있는 CA의 리스트에 포함되어야만 공인된 CA가 될 수 있는 것이다. CA의 리스트와 함께 각 CA의 공개키를 브라우저는 이미 알고 있다.

SSL 인증서가 서비스를 보증하는 방법

• 두가지 방식을 혼합해서 사용한다. 그렇기 때문에 SSL 통신방식이 공개키만 사용하는 것보다 복잡도는 높아지지만 성능상의 이점과 비밀정보 노출이 안되는 보안성이라는 장점을 갖고 있다.
  • 실제 데이터(아이디?비밀번호?기밀정보 등) : 대칭키
  • 대칭키의 키 : 공개키
• 양쪽 다 대칭키를 공유하고 있어야 한다. 대칭키를 공유할 때 사용하는 암호화 기법으로 공개키 방식을 사용한다.

https://opentutorials.org/course/228/4894
https://www.leafcats.com/202