[네트워크] HTTPS 그리고 보안 (암호화/인증서/전자서명)

a.very·2021년 7월 20일

TSL https https보안 ssl 공개키암호화 디지털서명 인증서 전자서명

CS-Study

목록 보기

4/6

https://github.com/WeareSoft/tech-interview/blob/master/contents/network.md 의 내용을 다룸

HTTPS 그리고 보안

HTTP와 HTTPS의 가장 큰 차이점은 SSL 인증서이다. SSL인증서는 클라이언트와 서버간의 통신을 공인된 제 3차 업체(CA)가 보증해주는 전자화된 문서이다.

SSL 인증서는 사용자가 사이트에서 제공하는 정보를 암호화한다.
암호화되어 전송되는 데이터는 중간에 누가 훔치거나 조작하려해도 암호화 되어있어서 해독할 수 없다.

🐬 SSL과 TLS

SSL(Secure Socket Layer)와 TLS(Transport Layer Security)는 같은 것이라고 볼 수 있다.
SSL은 TLS의 과거 명칭
SSL은 TCP/IP 암호화 통신에 사용되는 규약으로써 넷스케이프에서 만들었으며, SSL 3.0 버전에서부터 IETF에서 표준으로 정해서 TLS 1.0이 되었다. 하지만 보통 SSL로 많이 불려진다.
즉, TLS 안에 SSL이 속한다.

🐬 인증서의 장점

통신 내용이 노출, 변경되는 것을 방지해준다.
클라이언트가 접속하려는 서버가 신뢰할 수 있는 서버인지 확인한다.
SSL 통신에 사용할 공개키를 클라이언트에게 제공한다.

그럼 어떻게 암호화 해야하지?

🐬 암호화 방법

암호화를 하는 방식은 크게 두가지로 나눌 수 있다.

대칭 : 양쪽 당사자가 공통의 개인키를 공유하는 경우
비대칭 : 당사자 중 한쪽이 비밀 키와 공개 키의 쌍, 공개 키 인프라(PKI) 기반을 갖는다.

대칭키

대칭형 방식은 양쪽 당사자가 공유한 시크릿에 의존하는데, 전송자는 정보를 암호화하는 데 사용하고 수신자는 동일한 방식과 키를 사용해 복호화한다. 이 방법의 문제는 양쪽 당사자가 서로 물리적인 만남 없이 시크릿을 협상(교환)하는 방법이라서 일종의 보안 통신 채널이 필요하다.

비대칭키(공개키)

공개 키와 개인 키의 개념을 기반으로 하는 비대칭 방식은 대칭 방식의 문제를 해결한다. 두 가지 키 중 하나로 평문을 암호화하면 다른 보완 키를 사용해야만 복호화할 수 있다. 이를테면 서로 안전하게 통신하고 싶은 두 당사자 앨리스와 밥이 있다고 가정하자(앨리스와 밥은 모든 튜토리얼과 보안 매뉴얼에 항상 등장하는 허구의 인물이므로 여기서는 그러한 전통을 따랐다). 앨리스와 밥은 공개 키와 개인 키의 쌍을 가졌다. 개인 키는 각 소유자만 알고 있으며 공개 키는 누구든 사용할 수 있다.

🐬 HTTPS의 원리 : 공개키 알고리즘 방식

공개키 방식 (PKI, Public Key Infrastructure)은 암호화, 복호화시킬 수 있는 서로 다른 키(공개키, 개인키)를 이용한 암호화 방법이다.

공개키: 인코딩 / 모두에게 공개 / 공캐키 저장소에 등록
개인키(비공개키): 디코딩 / 개인에게만 공개 / 클라이언트-서버 구조에서는 서버가 가지고 있는 비공개키

⇒ A키로 암호화를 하면 B키로 복호화를 할 수 있고, B키로 암호화를 하면 A키로 복호화를 할 수 있다.

⇒ 단점 : 대칭키보다 느리다.

⇒ ex ) RSA

클라이언트 -> 서버
- 사용자의 데이터를 공개키로 암호화 (공개키를 얻은 인증된 사용자)
- 서버로 전송 (데이터를 가로채도 개인키가 없으므로 복호화할 수 없음)
- 서버는 서버만 알 고 있는 개인키를 통해 복호화하여 요청 처리

HTTPS를 지원하는 서버에 요청을 하려면 공개키다 필요하다.

그럼 이 공개키를 어떻게 공개키 저장소에서 가져올까?

또한 공개키는 누구나 얻을 수 있고, 공개키를 알면 서버가 주는 데이터(Reponse)는 아는데 보안상 의미가 있을까?
⇒ 결론 : 보안상의 의미는 없다.
⇒ 대신 해당 서버로 부터 온 응답임을 확신할 수 있다. 왜냐면 공개키로 해독이 가능한 것은 해당 서버의 개인키로 암호화했다는 것을 보장하기 때문이다.

🐬 (REAL WORLD)하지만 공개키 방식은 대칭키보다 느리다.

HTTPS 통신에서는

실제 전송되는 데이터의 암호화에는 대칭키 암호화 방식을 사용하고,
키 교환에는 공개키(비대칭키) 암호화를 사용하여

처리 속도가 느린 문제를 해결하고 있다.

🐬 전자서명과 인증서

전자서명이란 서명자를 확인하고 서명자가 했다는 사실을 나타내는데 이용하려고 특정 전자문서에 첨부되거나 논리적으로 결합된 전자적 형태의 정보이다.

→ 말그대로 서명하는것 / 서명을 통해서 서명한 사람을 확인하는 용도로 사용하는 것이다.

→ 공개키 암호를 이용하면 통신간의 인증 및 변조 검증이 가능하다.

디지털 서명(전자서명)

디지털 서명은 해싱→서명→검증 세가지의 기본 단계로 나뉜다.

정보를 해싱한다.
- 정보 해싱은 필수적인 부분은 아니다.
해시된 정보에 메시지 발신자의 서명을 작성한다(공개키로 암호화 된다).
- 이때의 서명에서 개인 키가 포함되지 않는 경우, 메시지 수신자는 유효성을 검증하기 위해 상응하는 공개 키를 사용할 수 없다. 공개키와 개인키는 모두 메시지 발신자에 의해 생성되야하고, 수신자에게는 공개키만 공유된다.
메시지 수신자는 발신자가 제공한 공개키를 통해 디지털 서명의 유효성을 확인할 수 있다.
- 이는 발신자만이 공개키에 상응하는 개인키를 가지고 있기 때문이다.

디지털 서명이 중요한 이유

데이터 무결성: 수신자는 발신자의 메시지가 전송되는 과정에서 변경되지 않았음을 검증할 수 있다. 메시지가 수정되면 전혀 다른 서명이 생성되기 때문.
진위성: 발신자의 개인 키가 안전하게 보관되는 한, 수신자는 해당 디지털 서명이 다른 이가 아닌 발신자에 의해 생성됐음을 확신할 수 있다.
부인방지: 발신자의 개인키가 노출되지 않는 이상, 발신자는 서명 사실을 부정할 수 없다.

서명방식과 그 모순

서명은 공개키기반구조(PKI)라는 구조를 형성하여 서로간의 인증을 통해 신뢰를 형성하는 방식이다. 서명방식에서는 개인키로 데이터를 암호화한다.

아래그림에서 앨리스가 메세지를 보낼때, 원본 message를 hash한 값을 자신의 개인키로 암호화 하여 전자 서명을 생성하여 message와 함께 밥에게 보낸다.

밥은 앨리스의 공개키를 이용해서 해당 서명을 복호화하여(decryption) 나온 해시값과 원본 message를 해시하여 나온 값을 비교한다. 이 값이 일치하면, 서로 통신 간의 데이터 변조가 일어나지 않음을 검증할 수있다.

🔥🔥 하지만, 전자 서명만으로는 공개키 소유자에 대한 인증이 불가능하다.

아래 그림은 공개키 암호방식과정이다. 데이터 암호에는 메시지를 받을 사람(Alice)의 공개키로 암호화를 수행하여 보냈다. 하지만 만약에 해커가 앨리스의 공개키를 가로채고 본인의 공개키로 보냈다고 생각해보자.

밥은 그러면 해커릐 공개키로 암호화하여 보낼 것이고, 해커는 자신의 개인키로 복호화하여 그 내용을 볼 수 있다.

⇒ 공개키 기반의 암호화가 완벽하지만 공개키의 유효성이 확인되지 않으면 무용지물이다.

⇒ 그래서 탄생한 것이 PKI기반의 인증서체인 (Cert Chain)형태이다.

🐬 인증서

인증서는 공개키의 유효성, 무결성을 보증한다
즉, 위의 그림에서 밥에게 공개키를 전달할때, 해당 공개키가 포함된 인증서를 보내는 것이다.

PKI

공개키 기반구조로, 인증서를 통해 서로 신뢰할 수 있는 구조이다.

PKI의 최상위에는 인증기관인 CA(Certificate Authority) 가 있다. CA는 공개키저장소라고도 불리며 민간기업이지만 아무나 운영할 수 없고 검증된 기업만 CA를 운영할 수 있다.

Step 1-3

이 CA에 공개키가 자신의 것이라는 것을 보증하기 위해 등록을 한다. CA에 공개키를 주면 CA가 공개키와 각종 정보들을 포함하여 cert를 구성해준다. 이렇게 생성된 인증서는 서명(Signature)와 함께 전달하게 된다.

인증서에 서명값이 포함된다고 보면된다.

인증서(cert) = 공개키(public key) + 공개키 해시(public key hash) + 서명값(signature) + 기타

Step 4. 앨리스는 전달받은 서명값(signature)을 확인한다.

CA의 공개키를 이용해서 복호화해 나온 앨리스의 공개키에 대한 해쉬값

Step 5. (Verification) Step4에서 구한 CA의 공개키를 이용해서 복호화해 나온 앨리스의 공개키에 대한 해쉬값과 인증서에 있는 공개키 해쉬 값을 비교하여일치하는지 판단

사실 이과정에서도 CA의 공개키가 유효한지 여부를 판단해야한다. CA의 공개키에 대한 Cert도 최상위 기관인 root CA에서 직접 만들어서 받는다

이러한 과정을 걸친 앨리스는 자신의 공개키에 대한 인증서를 가지고 있기 때문에 밥과 통신 시 이 인증서(서명값 포함)만 전달하면 된다. 밥도 마찬가지로 자신의 공개키에 대한 인증서를 가지고 있으면 앨리스에게 전달하여 서로간의 신뢰할 수 있는 통신을 할 수 있다.

인증서체인

사실 CA로 부터 인증서를 바로 발급받는 일은 거의 없다. PKI 에서 사실 CA는 최상위 기관이며, CA에서 모든 개인에게 모든 인증서를 발급해주기에는 무리가 있기 때문이다. 그래서 인증서 체인 형태로 관리하게 된다.

그림과 같이 상위인증기관이 하위 공개키에 대한 인증서를 만들어 주기때문에 체인형태로 보증이 가능하다.
CA에서 발급받는 형태와 동일하게, 앨리스에게 누군가가 공개키를 전달하면, 앨리스는 자신의 개인키로 서명을 만들어서 인증서를 발급해 줄 수 있다
물론 실제 세상에서는 인증받은 기관만이 저 체인에서 새로운 공개키를 발급시켜주겟죠?

CA (인증기관)

HTTPS 통신은 제 3자 인증을 사용합니다. 인증기관으로부터 인증서를 발급받아서 서버에 설치해야 경고없이 HTTPS 통신이 가능합니다.

인증기관의 인증을 받았다는 것은 웹서비스를 제공하는 소유자를 보증해준다는 의미다. 자세히는 웹 서비스 제공자의 공개키가 소유자의 것이라는 것을 보증해주는 말과 같다.

인증서는 공개키의 유효성, 무결성을 보증한다

위에서 이야기한 내용을 HTTPS 로 설명하자면

HTTPS로 웹서비스를 제공하려는 사람이 자신의 공개키와 개인키를 생성(공개키와 개인키를 생성하는 작업은 보통 CA에서 대신 생성해주기도 한다.)
공개키를 인증기관에 송부
인증기관은 보내온 공개키, 유효기관, 도메인 등의 정보를 포함하여 인증기관의 개인키로 전자서명한 인증서를 발급
웹 서비스를 제공하려는 사람은 발급 받은 인증서와 자신의 캐인키를 웹 서버에 설정하여 HTTPS 통신을 할 수 있게 한다.

웹 브라우저에는 이미 여러 인증기관의 공개키를 포함한 인증서가 설치되어 있다. 그래서 웹서버와 통신 시 인증기관의 개인키로 서명된 인증서를 받았을 때 이미 설치되어 있는 인증기관의 공개키로 복호화가 가능한것.

개발 목적이나 내부에서 사용할 목적으로 사설 인증서를 만들 경우 웹 브라우저에 인증서를 수동으로 설치해야만 경고 없이 통신이 계속 가능하다.

HTTPS 인증서의 종류

두가지 기준으로 HTTPS 인증서를 나눠보고자 한다.
1. 신원검증
2. 다루는 도메인의 수

1. 신원검증

DV (Domain validated) : 가장 일반적인 유형의 인증서인 DV 인증서
- 해당 도메인에 대한 알맞은 공개 키인지를 간단히 확인하며 브라우저에서는 법적 신원을 보여주지는 않는다.
- 브라우저는 서버와 보안 연결을 수립하고 닫힌 자물쇠를 표시한다.
- 도메인 외의 다른 특별한 요구 사항은 없다.
EV (Extended validation)
- 웹사이트의 법적 신분을 검증한다.
- 가장 신뢰할 수 있는 유형의 인증성 (인증 기관에서 도메인을 관리하는 이의 법적 신원을 확인한 후 얻을 수 있다.)
- 법적 신원은 다음의 조합으로 확인
  - 메인 관리(예: DV 인증서)
  - 회사가 등록되었고 현재 유지 상태인지 확인할 수 있는 공인된 사업 기록
  - D&B(Dunn and Bradstreet), 세일즈포스 connect.data.com, 전화번호부 등에 등재된 자영업 정보
  - 확인 전화
  - 인증서의 모든 도메인 이름 검사(와일드카드는 EV 인증서에서 명시적으로 금지). 닫힌 자물쇠 표시뿐만 아니라 EV HTTPS 인증서는 URL 앞에 검증된 법적 신원의 이름(등록된 회사)을 표시한다. iOS 사파리와 같은 일부 기기는 검증된 법적 신원만 표시하고 전체 URL은 무시한다. 해당 표시를 클릭하면 이름과 주소 같은 조직에 대한 자세한 정보를 보여준다. 비용은 연간 150달러에서 300달러 정도다.
OV (Organization validated)
- EV처럼 OV 인증서는 웹사이트의 법적 신분을 검증한다.
- 하지만 EV 인증서와 달리 OV HTTPS 인증서는 UI에서 확인된 법적 이름을 표시하지는 않는다.
- 결과적으로 OV 인증서는 높은 검증 요구 사항 대비 사용자에게 보여주는 이점이 없기 때문에 인기가 덜하다.

2. 다루는 도메인의 수

단일 도메인 가장 흔한 인증서 유형으로 example.com과 www.example.com와 같은 도메인 이름에 유효하다.
다중 도메인(UCC/SAN) UCC(Unified Communications Certificate)또는 SAN 인증서로 알려진 인증서 유형으로 도메인의 목록을 다룰 수 있다(지정된 제한까지). 단일 도메인에 대한 제한은 없으며 다른 도메인과 하위 도메인을 혼합할 수 있다.
와일드카드 이 유형의 인증서는 주 도메인뿐만 아니라 하위 도메인(.example.com)의 수를 제한 없이 다룬다(예: example.com, www.example.com, mail.example.com, ftp.example.com 등). 제한 사항은 주 도메인의 하위 도메인만 다룬다는 점이다.

표 webactually.com

출처

a.very

🚚chanhee-jeong.tistory.com 🚀 github.com/chaneeii/iOS-Study-Log

이전 포스트

[네트워크] HTTP와 HTTPS

다음 포스트