HTTP / HTTPS / SSL

HTTPS와 SSL 인증서, SSL 동작방법

 

1. HTTP & HTTPS

• HTTP

• 인터넷 상에서 정보를 주고 받기위한 프로토콜 (양식과 규칙의 체계)

• 클라이언트와 서버 사이에 이루어지는 요청/응답 프로토콜

• 암호화되지 않은 방법으로 데이터를 전송한다. (악의적인 감청, 데이터 변조의 가능성)

• HTTPS

• 보안이 강화된 HTTP

• Hypertext Transfer Protocol Over Secure Socket Layer의 약자

• 모든 HTTP 요청과 응답 데이터는 네트워크로 보내지기 전에 암호화된다.

• HTTPS는 HTTP의 하부에 SSL과 같은 보안계층을 제공함으로써 동작한다.

• HTTPS는 TCP위에 놓인 보안계층(SSL) 위의 HTTP이다.

 

1. SSL 디지털 인증서

• 클라이언트와 서버간의 통신을 공인된 제3자(CA, Certificate Authority) 업체가 보증해주는 전자화된 문서, 즉 SSL은 CA라 불리는 서드 파티로부터 서버와 클라이언트의 인증을 하는데 사용된다. 아래는 SSL 작동의 간단한 과정을 설명.

• [웹 브라우저] - SSL로 암호화된 페이지를 요청하게 된다.  Ex) https://www.xxx.com 사용

• [웹 서버] - Public Key(공개키)를 인증서와 함께 전송한다. 웹 브라우저에게(즉 사용자)

• [웹 브라우저] - 인증서가 자신이 신용있다고 판단한 CA(일반적으로 trusted root CA라고 불림)로부터 서명된 것인지 확인한다. (역주 : Internet Explorer, Netscape와 같은 웹 브라우저에서는 이미 ‘Verisign, Thawte’와 같은 널리 알려진 root CA의 인증서가 설치되어 있다) 또한 날짜가 유효한지, 인증서가 접속하려는 사이트와 관련되어 있는지 확인한다.

• [웹 브라우저] - Public key를 사용해서 랜덤 대칭 암호화키(Random symmetric encryption key)를 비롯한 URL, http데이터들을 암호화해서 전송한다.

• [웹 서버] - Private Key를 이용해서 랜덤 대칭 암호화키와 URL, http 데이터들을 복호화한다.

• [웹 서버] - 요청받은 URL에 대한 응답을 웹 브라우저로부터 받은 랜덤 대칭 암호화키를 이용하여 암호화해서 브라우저로 전송한다. 

• [웹 브라우저] - 대칭 키를 이용해서 http데이터와 html문서를 복호화하고, 화면에 정보를 뿌려준다.

 

• SSL 인증서와 장점 및 역할

• 통신 내용이 노출, 변경되는 것을 방지

• 클라이언트가 접속하려는 서버가 신뢰할 수 있는 서버인지 확인 가능

• SSL 통신에 사용할 공개키를 클라이언트에게 제공한다.

• 인증서(Certificate) : 당신과 접속해 있는 사람이나 웹 사이트가 믿을 수 있는지 어떻게 판단할 수 있을까? 한 웹 사이트 관리자가 있다고 가정하자. 그 사람이 당신에게 이 사이트가 믿을만하다고(심각할 정도로) 열심히 설명했다. 당신이 그 사이트의 인증서를 설치해 주기를 바라면서 말이다. 한 두번도 아니고 매번 이렇게 해야한다면 귀찮지 않겠는가? , 인증서는 여러 부분으로 이루어져 있다. 아래는 인증서 속에 들어있는 정보의 종류이다.

• 인증서 소유자의 e-mail주소

• 소유자의 이름

• 인증서의 용도

• 인증서 유효기간

• 발행 장소

• Distinguished Name(DN)

• Common Name(CN)

• 인증서 정보에 대해 서명한 사람의 디지털ID

• Public Key

• Hash

• SSL의 기본구조는 당신이 인증서를 서명한 사람을 신뢰한다면, 서명된 인증서도 신뢰할 수 있다는 것이다. 이것은 마치 트리(Tree)와 같은 구조를 이루면서 인증서끼리 서명하게 된다. 그러면 최상위 인증서는? 이 인증서를 발행한 기관을 ‘Root Certifiacation Authority, 줄여서 Root CA’ 라고 부르며, 유명한 인증기관(역주:Verisign, Thawte, Entrust, etc)의 Root CA인증서는 웹 브라우저에 기본적으로 설치되어 있다. 이러한 인증 기관은 자신들이 서명한 인증서들을 관리할 뿐만 아니라 철회 인증서(Revoked Certificate)들도 관리하고 있다. 그러면 Root CA의 인증서는 누가 서명을 했을까? 모든 Root CA인증서는 자체 서명(Self Signed)되어 있다.

• CA(Certificate Authority)

• 디지털 인증서를 제공하는 공인된 기업 (Certificate Authority 혹은 Root Certificate)

• 대표적인 CA 서비스 제공 기업과 시장점유율

• Symantec (VeriSign, Thawte, Geotrust) with 42.9% market share

• Comodo with 26%

• GoDaddy with 14%

• GlobalSign with 7.7%

 

• SSL에서 사용하는 암호화의 종류

• 암호 : 텍스트를 아무나 읽지 못하도록 ‘인코딩’하는 알고리즘

• 키 : 암호의 동작을 변경하는 매개변수, 키에 따라서 암호화 결과가 달라지기 때문에 키를 모르면 복호화가 불가능하다.

 

• 대칭키 암호화 방식

• 인코딩과 디코딩에 같은 키를 사용하는 알고리즘

• 단점 : 발송자와 수진자가 서로 대화하려면 둘 다 공유키를 가져야 한다는 것이다.

• 대칭키를 전달하는 과정에서 키가 유출되면 암호의 내용을 복호화할 수 있기 때문에 위험

• 이를 보완하기 위해 나온 방법이 공개키 암호화 방식이다.

 

• 공개키 암호화 방식

• 인코딩과 디코딩에 다른 키를 사용하는 알고리즘

• A키로 암호화를 하면 B키로 복호화를 할 수 있고, B키로 암호화 하면 A키로 복호화 할 수 있는 방식

• 인코딩 키 (public key)는 공개되어 있으며 (그래서 공개키 암호방식이라는 이름이 붙었다) 보통 디지털 인증서 안에 포함되어 있다.

• 디코딩 키는 (secret key)는 호스트만이 개인 디코딩 키를 알고 있다.

• 공개키와 비공개키의 분리는 메세지의 인코딩은 누구나 할 수 있도록 해주는 동시에, 메세지의 디코딩은 비밀키 소유자에게만 부여한다.

• 이는 클라이언트가 서버로 안전하게 메세지를 발송하는 것을 쉽게 해준다.

• 단점 : 공개키 암호화 방식의 알고리즘은 계산이 느린 경향이 있다.

 

• 대칭/비대칭키

• Private Key/Public Key 알고리즘은 대단하지만 비실용적이라는 단점이 있다. 비대칭(Asymmetric)이란 하나의 키로 암호화를 하면 다른 키가 있어야 복호화를 할 수 있다는 것을 뜻한다. 즉, 하나의 키로 암호화/복호화를 할 수 없다는 말이다. 

• 대칭키(symmetric Key)는 하나의 키로 암호화/복호화를 하게 된다. 대칭키를 사용하면 비대칭키보다 훨씬 빠르게 암호화/복호화를 할 수 있다. 그렇지만 속도 때문에 대칭키를 이용한다는 것은 너무 위험하다.

• 만약 해커가 키를 입수할 시 기존의 암호화된 정보가 모두 무용지물이 되버리기 때문에 대칭키 알고리즘을 사용한 키를 상대방에게 전송하려면 인터넷을 통한 전송은 유출 위험이 크다. 이에 대한 대응책으로 대칭키를 비대칭키로 암호화시켜서 전송하는 방법이 있다. (역주 : 웹서버와 웹브라우저의 관계 참고) 자신의 Private Key만 안전하게 관리하면 Public Key로 암호화되어 안전하게 전송할 수 있다. (여기서 보안은 죽음이나 협박 등을 제외한다) 또한 대칭키는 매번 랜덤으로 선택되는데, 이렇게 되면 만약 대칭키가 누출되어도 다음번에는 다른 키가 사용되기 때문에 안전하다.

 

• 개인키/공개키 (Private Key / Public Key)

• Private Key / Public Key를 이용한 암호화는 하나의 키로 암호화하고 나머지 다른 하나로 복호화 할 수 있도록 되어 있다. (글쓴이의 주장, 역주 : 독자가 PKI, Public Key Infrastructure)에 대해 잘 모른다면 이에 대한 간단한 문서를 읽어보기를 권함) 앞에서 암호화한 키로만 암호화를 할 수 있는 것이 아니라 반대 방향으로 복호화한 키로도 암호화 할 수도 있다. 이러한 키 쌍은 소수(prime number)로부터 생성되며, 그 길이(Bit단위)는 암호화의 강도를 나타낸다.

• Private Key / Public Key는 이러한 키쌍을 관리하는 방법이다. 한 개의 키는 안전한 장소에 자기만 알 수 있도록 보관하고(Private Key) 다른 하나는 모든 사람에게 퍼뜨리는 것(Public Key)이다. 그렇게 하면 그 사람들이 당신에게 메일을 보낼 때 암호화해서 보낼 수 있으며, 당신만이 그 암호를 풀 수 있다. 반대로 다른 사람에게 메일을 보낼 일이 있으면 Private Key를 이용해 암호화 할 수 있다. 그러면 그 사람들은 복호화해서 볼 수 있다. 그러나 이 방법은 모든 사람이 Public Key를 가지고 있어야 하기 때문에 그리 안전한 방법이 아니다.(역주 : 오히려 역효과 가능성이 있으며 단순하게 메세지, 파일에 암호화, 서명을 할 생각이면 PGP나 GnuPG를 권한다)

 

• 암호화 알고리즘(Encryption Algorithm)

• 암호화 알고리즘은 대칭이든 비대칭이든 간에 상당히 많은 종류가 있다. 일반적으로 암호화 알고리즘으로 특허를 낼 수 있다. 만약 Henri Paincare가 암호화 알고리즘으로 특허를 낸다면 Albert Einstein으로부터 고소당할 수 있는 것이다. 단, USA에서는 암호화 알고리즘으로 특허를 낼 수 있다. (역주 : 또한 군사법으로 보호받게 된다) OpenSSL의 경우에는 암호화 알고리즘으로 특허를 낼 수 없고, 군사법이나 보안법에 저촉되지 않는 국가에서 개발되고 있다.

• 실제로 알고리즘이 어떻게 사용될 수 있는지 살펴보자. 웹 서버와 브라우저는 서로 통신을 하는 동안 서로 어떤 알고리즘을 사용할 수 있는지 확인하게 된다. 다음에 서로 이해할 수 있는 일반적인 알고리즘을 선택한 후 통신이 이루어지게 된다. OpenSSL은 컴파일해서 삽입할 알고리즘을 택할 수 있다. 그렇게 하면 암호화 알고리즘에 제한을 걸고 있는 국가에서도 사용할 수 있게 된다.

• HASH

• 해쉬는 해쉬함수에 의해 만들어지는 숫자이다. 이 함수는 단방향으로 연산되는 함수이다. 즉, 한번 해쉬함수로 원본으로부터 해쉬값을 생성했다면, 해쉬값으로부터 원본 메세지를 알아내는 것이 불가능하다. 해쉬의 용도는 원본 메세지가 손상이 되었는지를 알아내는데 있으며, 해쉬값을 변경시키지 않고 원본을 조작하는 것은 극히 어렵다. 그래서 해쉬 함수는 패스워드 메커니즘을 비롯한 소프트웨어의 손상 유무(MD5 sum)를 가리는데도 이용할 수 있으며, 메세지의 손상을 방지하기 위해 널리 쓰이고 있다.

• 서명

• 서명은 특정 메세지를 내가 작성했다는 것을 인증하는 역할을 한다. Text가 될 수도 있고, 인증서 등등이 될 수 있다. 메세지에 서명하기 위해서는 아래의 순서를 따라야 한다.

• 해쉬 생성

• Private Key로 해쉬 암호화

• 암호화된 해쉬와 서명된 인증서를 메세지에 추가

• 받는 사람은 따로 해쉬를 생성

• 받은 메세지에 포함된 해쉬를 Public Key를 이용해서 복호화

• 4,5번 과정에서 생성된 해쉬를 비교

 

• 디지털 서명의 동작 방식

• 전자 서명을 통해서 누가 메세지를 썻는지 알려주고, 메세지가 위조되지 않았음을 증명할 수 있다. 정자서명은 SSL 인증서에서 서비스를 보증하는 방법으로 활용된다.

• 공개키와 비공개키는 안전한 데이터 전달 이외에도, 데이터 제공자의 신원을 보장하는데 사용할 수 있다.

• 비공개키의 소유자가 비공개 키를 이용해서 정보를 암호화 -> 공개키와 함께 암호화된 정보를 전송 -> 수신자는 공개키로 암호화된 정보를 복호화

• 암호화된 데이터를 공개키를 가지고 복호화 할 수 있다는 것은 그 데이터가 공개키와 쌍을 이루는 비공개키에 의해서 암호화 되었다는 것을 의미

• 즉 공개키가 데이터를 제공한 사람의 신원을 보장해주게 되는 것이다. 이러한 것을 전자서명이라고 부른다.

 

• SSL 인증서의 서비스 보증방법 및 동작방법

• 인증서 내용

• 인증서의 내용은 CA의 비공개 키를 이용해서 암호화 되어 웹 브라우저에게 제공

• 서비스 정보(인증서 발급자, CA의 디지털 서명, 서비스 도메인)

• 서버 측 공개키

 

• SSL 인증서의 서비스 보증방법

• 웹브라우저가 서버에 접속하면 서버는 제일 먼저 인증서를 제공

• 브라우저는 인증서를 발급한 CA가 자신이 갖고있는 CA 리스트에 있는지 확인

• 리스트에 있다면 해당 CA의 공개키를 이용해서 인증서를 복호화

• 인증서를 복호화 할 수 있다는 것은 이 인증서가 CA의 비공개키에 의해서 암호화된 것을 의미, 즉 데이터를 제공한 사람의 신원을 보장해주게 되는 것

• SSL 동작방법

• 공개키 암호 방식은 알고리즘 계산방식이 느린 경향이 있다.

• 따라서 SSL은 암호화된 데이터를 전송하기 위해서 공개키와 대칭키 암호화 방식을 혼합하여 사용한다.

• 안전한 의사소통 채널을 수립할 때는 공개키 암호를 사용하고, 이렇게 만들어진 안전한 채널을 통해서 임시의 무작위 대칭키를 생성 및 교환한다. 해당 대칭키는 나머지 데이터 암호화에 활용

• 실제 데이터 암호화 방식 : 대칭키

• 상기 대칭키를 서로 공유하기 위한 암호화 방식 : 공개키

• SSL 통신과정’

• 컴퓨터와 컴퓨터가 네트워크를 통해서 통신을 할 때 “핸드쉐이크 -> 세션 -> 세션종료” 의 과정을 거침

• 암호화된 HTTP메세지를 교환하기 전에 클라이언트와 서버는 SSL 핸드쉐이크를 진행

• 핸드쉐이크의 목적은 다음과 같다.

• 프로토콜 버전번호 교환

• 양쪽이 알고 있는 pre master secret 키 생성 및 교환

• 양쪽의 신원인증

• 채널을 암호화 하기 위한 임시 세션 키 생성

• SSL 통신과정을 간단하게 도식화 하면 아래와 같다.

• 생활코딩 SSL 동작방법 참고

 

• 암호문(Pass Phrase)

• 암호문(Pass Phrase)은 기존의 패스워드(Password)를 확장한 시스템. 예전의 Unix 시스템의 암호는 8자가 한계였다. 암호문이라는 것은 단순히 암호의 한계가 더 길어졌다는 것을 뜻한다. 당연히 8자가 한계인 것보다 보안이 강력하다. 최근의 Unix시스템은 MD5를 사용하고 있기 때문에 암호의 길이 제한이 없어짐

• 암호문은 SSL에서 키가 누출되었을 경우, 최종 보안 장치이기 떄문에, 중요한 키에는 반드시 새겨두어야 한다.

 

 

HTTPS (feat. http)

HTTPS에 대해 알아보기 전에 HTTP를 간단하게 설명할 수 있으면 좋다.

HTTP는 HyperText Tranfer Protocol로 WWW상에서 정보를 주고 받는 프로토콜이다.

클라이언트인 웹브라우저가 서버에 HTTP를 통해 웹페이지나 이미지 정보를 요청하면 서버는 이 요청에 응답하여 요구하는 정보를 제공하게 된다.

결국, HTTP 는 웹브라우저(Client)와 서버(Server)간의 웹페이지같은 자원을 주고 받을 때 쓰는 통신 규약이다.

http는 텍스트 교환이다. html페이지도 텍스트다. 바이너리 데이터로 되어있는 것도 아니고 단순 텍스트를 주고 받기 때문에 누군가 네트워크에서 신호를 가로채어 본다면 내용이 노출된다.

이런 보안상의 문제를 해결해주는 프로토콜이 HTTPS다.

---

HTTPS는 인터넷 상에서 정보를 암호화하는 SSL(Secure Sockey Layer)프로토콜을 이용하여 웹브라우저(클라이언트)와 서버가 데이터를 주고 받는 통신 규약이다.

HTTPS는 http 메세지(text)를 암호화하는 것이다.

HTTPS의 S가 Secure Socket, 보안 통신망을 말한다.

HTTPS의 암호화 원리를 간단히 알아보면 핵심은 공개키 암호화 방식이다.

<출처 : http://cryptocat.tistory.com/3 >

암호학을 공부하는게 아니니 공개키 알고리즘을 간단하게만 소개하겠다.

암호화, 복호화시킬 수 있는 서로 다른 키 2개가 존재하는데 이 두 개의 키는 서로 1번 키로 암호화하면 반드시 2번키로만 복호화할 수 있고 2번 키로 암호화하면 반드시 1번키로만 복호화할 수 있는 룰이 있는 것이다.

그 중에서 하나 키는 모두에게 공개하는 공개키(1번 키)로 만들어서 공개키 저장소에 등록해놓는다.

서버는 서버만 알 수 있는 개인키(2번 키)를 소유하고 있으면 된다.

그러면 1번키로 암호화된 http 요청, 즉 HTTPS 프로토콜을 사용한 요청이 온다면 서버는 개인키(2번 키)를 이용하여 1번키로 암호화된 문장을 해독하게 된다.

서버는 요청이 무엇인지 알게되고 요청에 맞는 응답을 다시 개인키(2번 키)로 암호화해서 요청한 클라이언트에게 보내주게 된다.

그리고 응답을 받은 클라이언트는 공개키(1번 키)를 이용해서 개인키(2번 키) 암호화된 HTTPS 응답을 해독하고 사용하는 시나리오다. (* 공개키 암호화 방식에 대한 이해를 위한 설명일 뿐 더 정확한 HTTPS 연결 과정은 아래에 따로 정리 했습니다.)

HTTPS를 지원하는 서버에 요청(Request)을 하려면 공개키가 필요하다는 것을 알 수 있다.

그러면 그 공개키는 공개키 저장소에 있다는 것은 알겠는데 어떻게 공개키 저장소에서 가져올까?

추가적으로 공개키는 누구나 얻을 수 있고 공개키를 알면 서버가 주는 데이터(Response)는 알 수 있는데 보안상에 의미가 있을까?

보안상의 의미는 없다.

대신 얻을 수 있는 이점은 해당 서버로부터 온 응답임을 확신할 수 있다. 왜? 공개키로 해독이 가능했으니까 반드시 해당 서버의 개인키로 암호화했다는 것을 보장하기 때문이다.

---

조금 더 자세한 HTTPS 통신 흐름

아까 의문을 가졌던 것을 다시 생각해보자.

공개키가 공개키 저장소에 있는데 어떻게 가져올 수 있을까?

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

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

CA는 민간기업이지만 아무나 운영할 수 없고 신뢰성이 검증된 기업만 CA를 운영할 수 있다.

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를 날리게 되겠죠.

---

이런 구성입니다만,

HTTPS를 지원한다고 해서 무조건 안전한 것은 아닙니다.

왜냐하면 신뢰할 수 있는 CA 기업이 아니라 자체적으로 인증서를 발급할 수도 있고, 신뢰할 수 없는 CA 기업을 통해서 인증서를 발급받을 수도 있기 때문입니다.

그렇게 되면 브라우저에서는 https지만 "주의 요함", "안전하지 않은 사이트"등의 알림을 주게됩니다.

 

 

 

https://opentutorials.org/course/228/4894

http://coffeenix.net/board_view.php?bd_code=1661