안녕하세요.

오늘은 HTTPS 통신 에 대해 포스팅 합니다.

HTTPS 통신 은 데이터를 암호화 하여 통신하도록 설계되어 보안적인 요소가 강화된 HTTP 통신 입니다.

HTTPS 통신 은 HTTP 통신 과 다르게 서버가 제공하는 SSL 인증서 라는 요소가 추가되었으며, 이를 통해 클라이언트는 필요한 서버의 정보를 취득하고 신뢰성을 판단합니다.

데이터 암호화

HTTPS 통신 방법에 앞서, 간단하게 데이터 암호화 개념을 살펴보면 좋습니다.

암호화 란 평문을 암호문으로 변경하는것을 의미합니다.

반대로 복호화 는 암호문을 평문으로 변경하는것을 의미합니다.

평문: 사람이 이해할 수 있는 데이터

암호화는 어떤 특정 데이터를 사용하여 수행하는데, 이 특정 데이터를 암호키 라고 부릅니다.

암호화는 크게 두가지 방식이 있습니다.

• 대칭키 방식

• 공개키 방식

대칭키 방식

대칭키 방식은 말그대로 암호키 가 대칭임을 의미 합니다.

암호화 할때도, 복호화 할때도 똑같은 1개의 암호키 를 사용하는 것이 특징입니다.

통신 하려는 대상 서로가 암호키 를 알고 있으면 매우 유용합니다.

하지만 불특정 다수와 통신을 하기 위한 안전한 암호키 전달이 무척 어렵습니다.

해커가 중간에 암호키 를 취득 해버리면 데이터를 암호화 하는게 의미가 없기 때문입니다.

Q. 암호키 도 암호화 해서주면 안되나요? A. 암호화 를 하기위해서는 무조건 최초로 평문으로된 암호키 를 넘겨주어야만 합니다. 암호키 를 암호화 해버리면 클라이언트는 복호화 를 할 수 있는 키를 모르기 때문입니다.

공개키 방식

공개키 방식은 암호키 가 두가지 존재합니다.

• 공개키

• 비공개키(개인키, 비밀키)

대칭키 방식 과는 다르게 암호화 할때 공개키를 사용했으면 복호화 는 비밀키 를 사용해야 합니다.

반대로, 암호화 할때 비밀키 를 사용했다면 복호화 는 공개키 로만 가능합니다.

공개키 방식의 장점

공개키 방식 은 대칭키 방식 의 키를 안전하게 전달하기 어려운 단점을 어느정도 해소 하였습니다.

서버가 개인키 를 소유하고 있고, 불특정 다수에게 공개키 를 전달합니다.

이때, 해커가 공개키 를 획득 할 수 있고 그로인해 서버가 내려주는 데이터 를 해석은 할 수 있지만 클라이언트에게 공격하지는 못합니다.

예를들어, 서버가 클라이언트에게 A의 장소 를 알려줬습니다. 이때 해커는 공개키 를 취득해 복호화 하여 내용을 읽었고 클라이언트에게 B의 장소 로 속이고 싶습니다.

해커가 데이터를 변경하더라도 서버가 가지고 있는 비밀키 를 알아야 클라이언트가 속을 수 있는 암호문 을 만들 수 있습니다.

해커가 임의로 암호문을 만들어버리면 클라이언트는 공개키 로 복호화에 실패할것이고, 결국 클라이언트에게 공격하지 못하는 상황이 발생합니다.

물론 클라이언트가 서버의 서비스를 이용 못하는건 있습니다. 하지만 공격 받지 않는것이 핵심입니다.

반대로 클라이언트가 서버로 데이터를 보낼 때는 공개키 로 데이터를 암호화 하여 보냅니다.

해커는 공개키 만알고 있기 때문에 클라이언트 데이터를 읽지 못합니다. 왜냐면 공개키 방식 은 공개키 로 암호화 를 하면 비밀키 로만 복호화 를 진행할 수 있기 때문입니다.

정리하자면 공개키 방식 은 클라이언트로 하여금 데이터가 변경되지 않음을 보장할 수 있고 안전하게 데이터를 서버로 보낼 수 있는 장점이 있습니다.

공개키 방식의 단점

하지만 공개키 방식도 한계가 존재합니다. 클라이언트 → 서버로 데이터를 암호화 해서 보내는건 문제가 되지 않습니다. 해커가 읽지도 못하니깐요.

하지만 서버 → 클라이언트로 보내는 데이터는 해커가 읽을 수 있습니다. 만약 데이터가 민감한 개인 정보같은게 포함되어 있다면 해커가 읽는것만으로도 피해가 생길 수 있기 때문입니다.

또한 공개키 방식 은 대칭키 방식 보다 암-복호화 속도가 느립니다.

SSL 인증서

HTTPS 통신 에서는 서버가 SSL 인증서 를 제공한다고 언급했습니다.

이 SSL 인증서는 크게 두가지 역할을 수행합니다.

• 서버 본인이 신뢰할 수 있는 서버임을 증명하는 수단.

• 서버가 제공하는 공개키를 전달.

SSL 인증서 는 서버의 신뢰성을 판단할 수 있는 수단이라 했는데, 다짜고짜 클라이언트에게 SSL 인증서 를 내밀면 신뢰할 수 있을까요?

예를들어, 모르는 사람이 다가와서 나 믿을 수 있는 사람이야 라고 말하면 여러분을 믿을 수 있으신가요?

그렇기에 SSL 인증서 의 신뢰성을 대신 보장하는 제 3자가 존재합니다.

그 3자를 CA(Certificate authority) 혹은 Root Certificate 라 일컫는 기업들입니다.

해당 기업들은 세계적인 기업으로써, 신뢰성이 엄격하게 공인된 기업들만 CA로써, 참여할 수 있습니다.

이러한 기업은 SSL 인증서 를 신청한 기업들이 신뢰성있는 기업인지 평가한 후 발급을 진행합니다.

CA 기업들은 잘 알려진 기업들로써, HTTPS 통신을 지원하는 클라이언트(대표적으로 브라우저)들은 CA 리스트 를 보유하고 있습니다. 그렇기에, 클라이언트는 SSL 인증서 를 받은 후 정보를 읽어 CA 리스트 대조를 통해, CA 가 발급한 SSL 인증서 의 유무를 판단하고 신뢰성을 평가합니다.

CA 가 발급하지 않은 SSL 인증서 는 클라이언트가 신뢰성을 낮게 평가합니다.

SSL 인증서 암호화

SSL 인증서는 비공개키 방식 으로 암호화하여 클라이언트에게 전달됩니다.

이때, 암호화 를 수행하는 대상은 서버가 아닌, CA 에서 자체적으로 소요한 비밀키 를 통해 암호화 를 진행합니다.

즉 SSL 인증서 를 서버에서도 변조하여 클라이언트에게 공격할 수 없습니다. 비밀키 를 모르기 때문입니다.

CA 의 공개키는 이미 널리 알려진 정보로써, 클라이언트가 CA 리스트 와 함께 공개키 도 보유하고 있습니다. 그렇기에 위에 앞서 언급한 공개키 방식 장점을 잘 활용하고 있다고 볼 수 있습니다. SSL 인증서 가 위조되지 않음을 보장받을 수 있기 때문입니다.

SSL 인증서에 포함된 공개키

SSL 인증서엔 공개키가 포함되어 있는데 이는, CA 의 공개키가 아닙니다. 서버가 클라이언트와 보안 통신을 하기위해 서버가 직접 생성한 공개키 입니다.

서버가 CA 에게 SSL 인증서 의 발급 신청을 할 때, 몇몇 서버 데이터를 전달하는데 필수적으로 공개키 도 전달이 되어야 합니다.

뒤에 설명할 SSL 통신 에서는 클라이언트가 SSL 인증서 를 통해 서버의 공개키 를 취득하고, 비공개 방식 으로 보안 통신하는 절차가 있기 때문에 필수적으로 필요합니다.

SSL 통신

공개키 방식 으로 통신을 하면, 서버 → 클라이언트로 데이터를 내려줄땐 조금 문제가 될 순 있지만, 어느정도 감안하고 보안 통신 방법으로 사용할 수 있을거 같습니다.

하지만, 큰 단점이 있는데요.

그것은 바로 공개키 방식은 암호화 복호화 하는 과정이 느리다 라는 것 입니다.

웹통신이 느리면, 문제가 될 수 있기 때문에 SSL 통신 은 상대적으로 빠른 대칭키 방식 으로 메인 통신을 진행합니다.

하지만, 대칭키는 공격자가 알면 너무나도 쉽게 데이터를 변조하여 대상을 속일 수 있기 때문에 매우 위험합니다. SSL 통신은 어떻게 이런 이슈들을 해결했을까요?

SSL 통신 방법

결론적으로 말하자면, SSL 통신은 공개키 방식 과 대칭키 방식 둘 다 사용합니다.

SSL 통신은 다음의 아이디어를 사용합니다.

공개키 방식 으로 서버와 함께 작성된 대칭키 를 서로에게 전달합니다. 이때 중간 공격자는 서버의 개인키 를 알고있지 않는한 내용을 복호화하지 못하여 데이터 해독이 불가능 합니다.

이렇게 서로 안전하게 대칭키 가 전달되었다면, 암-복호화가 빠른 대칭키 로 데이터 통신을 합니다.

SSL 통신 절차

TCP와 같은 연결지향 프로토콜은 크게 아래의 과정을 거칩니다.

• 악수(HandShake)

• 데이터 전송(세션)

• 세션 종료

SSL 통신도 결국 TCP위에서 동작하므로, 위 과정과 같습니다만, 세부적인 내용이 조금 다릅니다.

SSL 통신은 TCP의 핸드쉐이크 (SYN → SYN ACK → ACK) 과정이 이루어 진 후에, SSL 통신이 시작됩니다. (악수 → 데이터 전송 → 세션 종료)

악수(HandShake)

1. Client Hello (클라이언트가 서버에 접속합니다. )
   • 서버에게 평문 문자열 Client Hello 를 전송합니다.
   • 서버에게 대칭키 를 만들 수 있는 랜덤 데이터를 평문으로 전송 합니다.

2. Server Hello (서버가 Client Hello 를 받은 후, 클라이언트에게 응답합니다.)
   • 클라이언트에게 평문 Server Hello 를 전송합니다.
   • 클라이언트에게 대칭키 를 만들 수 있는 랜덤 데이터를 평문으로 전송합니다.
   • 제일 중요한 SSL 인증서 를 전송합니다.

3. 클라이언트의 SSL 인증서 신뢰성 판단
   • 서버에게 받은 SSL 인증서 를 보유하고 있는 CA 리스트를 통해 복호화 합니다.
   • 복호화 에 성공하였다면, 해당 서버를 신뢰할 수 있다고 판단합니다.

4. 서버에 대칭키 전송 (SSL 핸드쉐이크의 핵심 목적 입니다.)
   • 클라이언트는 본인이 만든 랜덤 데이터와 서버에서 받은 랜덤 데이터를 이용하여, 대칭키 를 구성합니다.
   • 해당 대칭키를 SSL 인증서 에 포함되어 있는 서버 공개키로 암호화 하여 서버에게 전송합니다.

5. 핸드쉐이크 종료
   • 클라이언트와 서버가 서로 대칭키 를 안전하게 전달 받은 후, 통신 준비가 되었다는 신호와 함께 핸드쉐이크가 종료됩니다.

데이터 전송(세션)

서버와 클라이언트가 데이터를 서로 주고 받고 하는 단계입니다. 서로 안전하게 전달받은 대칭키 를 사용하여, 암-복호화를 빠르게 진행합니다.

세션종료

데이터 전송이 끝나면 SSL 통신이 끝났음을 서로에게 알려줍니다.

오늘 준비한 포스팅은 여기까지 입니다. 읽어주셔서 감사합니다.