HTTPS 개요

 

 

* 해당 게시글은 <그림으로 배우는 Http&Network Basic>을 읽고 정리하면서 공부하기 위해 메모하듯 작성하는 글입니다.

 

 

---

 

 

HTTP의 약점

1. 평문이기 때문에 도청 가능

• HTTP 자신을 암호화하는 기능의 부재→평문으로 HTTP 메시지 전송
• TCP/IP 구조의 통신 내용은 전부 통신 경로의 도중에 엿볼 수 있음
  • 암호화된 통신의 경우에도, 내용을 해석할 순 없으나 전송 패킷 자체는 도청이 가능
  • 네트워크 상의 패킷을 수집하기만 하면 도청 가능
    • 패킷 캡처
    • 스니퍼

암호화 방법

• 통신 암호화
  • 암호화 기능이 없는 HTTP에 SSL이나 TLS 등의 프로토콜을 조합해 HTTP의 통신 내용 암호화
    
    • SSL 등을 이용해 안전한 통신로 확립→해당 통신로로 HTTP 통신 진행
• 콘텐츠 암호화
  • HTTP를 사용해서 운반하는 내용(콘텐츠)만 암호화
  • 클라이언트에서 HTTP 메시지를 복호화해서 출력하는 처리 필요
    • 평상시 유저가 사용하는 브라우저와 웹 서버에서 이용하기 어려움
    • 주로 웹 서비스 등에서 이용되는 방법

2. 통신 상대 확인 과정이 없음

• 상대가 누구인지 확인하는 처리가 없어 누구든지 리퀘스트를 송신 가능하며, 서버는 리퀘스트에 맞춰 리스폰스를 반환
  • 서버 측에서 특정 IP주소나 포트 등을 제한하지 않는 것을 전제
• 리퀘스트를 보낸 곳의 웹 서버가 내가 아는 곳이 맞는지, 리스폰스를 보낸 위치(클라이언트)가 내가 아는 클라이언트가 맞는지 확정 불가
  • 위장한 클라이언트나 서버인지 확인 불가능
• 특정 상대한테서만 리퀘스트를 받고 싶으나 HTTP에서는 불가능

증명서

• HTTP에서는 상대를 확인할 수 없지만, SSL로 상대 확인 가능
• SSL은 암호화와 함께, 상대를 확인하는 수단으로 증명서 제공
  • 증명서는 신뢰할 수 있는 제3자 기관에 의해 발행→서버나 클라이언트가 실재하는 사실 증명 가능
  • 증명서를 위조하는 것은 상당한 기술력 필요→보안성 증가
• 통신 상대의 서버나 클라이언트가 가진 증명서를 확인함으로써 내가 통신하고자 하는 상대인지 판단 가능
• 효과: 이용자(클라이언트)의 개인 정보 누설 등의 위험성 감소
• 클라이언트가 증명서를 가짐으로써 본인 확인, 웹사이트 내 인증 가능

3. 메시지 변조 가능성

• HTTP는 리퀘스트나 리스폰스가 발신된 후에 상대가 수신할 때까지의 사이에 변조되었다 하더라도 해당 사실을 알 수 없음
• 중간자 공격
  • 공격자가 리퀘스트, 리스폰스 송신 도중 빼앗아 변조하는 보안 공격
• HTTP로 변조 방지하기 위한 시도 존재(아래 방법은 모두 클라이언트가 다운받은 파일을 직접 검사해야 함)
  • MD5나 SHA-1 등의 알고리즘을 통해 해시 값을 확인하는 방법
  • 파일의 디지털 서명 확인(PGP)
• 하지만 PGP와 MD5 자체도 적절하게 수정되어 있으면 유저 입장에서 메시지 변조 여부 확인 어려움

 

 

---

 

 

HTTPS

HTTP에 암호화와 인증, 완전성 보호 기능을 더한 프로토콜

• HTTP 통신을 하는 소켓 부분을 SSL이나 TLS라는 프로토콜로 대체하여 구현
  • 네트워크 통신시 HTTP가 TCP와 직접 상호작용하던 구조에서, HTTP와 TCP 사이를 SSL이 채워 HTTP와 SSL, SSL과 TCP가 서로 상호작용하는 구조로 변화
  • SSL은 HTTP와 독립된 프로토콜

HTTPS는 SSL의 껍질을 덮어 쓴 HTTP라고 볼 수 있음

 

 

---

 

 

암호화 방식

공통키 암호

• 암호화와 복호화에 하나의 키를 같이 사용하는 방식
  • 암호화해서 보내는 쪽도, 암호문을 받는 상대방도 키가 필요
• 네트워크를 사용해 키를 넘겨줄 때, 통신이 도청되어 공격자에게 키를 뺏길 위험성 존재

공개키 암호

• 공통키 암호의 문제를 해결하기 위해 고안
• 서로 다른 두 개의 키 페어(쌍) 사용
  • 비밀키(private key)-누구에게도 알려지면 안 되는 키
  • 공개키(public key)-누구에게나 알려져도 괜찮은 키
• 암호문과 공개키라는 정보로부터 평문(해독한 데이터)을 구하는 것은 수학적으로 매우 어려움

<공개키, 비밀키를 이용한 암호화/복호화 진행 과정>

1. 암호를 받는 측이 상대에게 공개키 전달
2. 암호를 보내는 측이 데이터에 공개키를 적용한 암호 송신
3. 암호를 받은 측이 비밀키를 사용해 복호화

HTTPS의 암호화 방식

• 공통키 암호화 공개키 암호를 적절히 섞어 사용
  • 공개키 암호는 공통키 암호보다 처리 속도가 느리기 때문에 둘의 장점을 조합한 방식이 필요
• 키를 교환하는 곳에서는 공개키 암호를, 그 후의 통신에서 메시지를 교환할 때는 공통키 암호 사용
  • 공통키 통신에서 사용하는 키를 교환할 때 공개키 암호 사용

 

 

---

 

 

증명서

• 공개키가 진짜인지 아닌지 구분할 수 없는 것이 공개키 암호의 문제점
• 위의 문제를 해결하기 위해 인증 기관(CA)이 발행하는 공개키 증명서 사용

인증 기관(Certificate Authority, CA) 

• 클라이언트와 서버가 모두 신뢰하는 제3자 기관
• 유명한 인증 기관: VerySign

<인증 기관과 증명서를 거친 공개키 암호화 방식>

1. 서버 운영자가 공개키를 CA로 전달
2. CA가 공개키 증명서를 서버로 전달
(CA 측의 비밀키로 암호화하여 전달)
3. 서버가 공개키 증명서를 클라이언트로 전달
4. 클라이언트 측에서 CA의 공개키로 증명서 복호화한 후 서버의 공개키 취득
5. 클라이언트가 서버 공개키로 암호화한 데이터를 서버로 전달
6. 서버의 비밀키로 암호문 복호화

• CA의 공개키는 안전하게 클라이언트에 전달되어야 함
  • 많은 브라우저가 주요 인증 기관의 공개키를 사전에 내장한 상태로 출시

EV SSL 증명서

• 서버가 올바른 통신 상대임을 증명함과 동시에 상대방이 실제로 있는 기업인지 증명하는 역할
• 세계 표준의 인정 가이드라인에 의해 발행되는 증명서
  • 엄격한 기준으로 발행되기 때문에 웹사이트의 신뢰성 더욱 증가

클라이언트 증명서

• 서버 측에서 현재 자신과 통신하고 있는 상대방이 자신이 의도했던 클라이언트인지 증명하는 증명서
• 클라이언트의 문제점
  • 증명서의 입수와 배포
    • 유저가 클라이언트 증명서를 설치해야 함
    • 클라이언트 증명서는 유료로 구입해야 하므로 유저 수만큼 비용 소요
    • 여러 유저가 설치 작업을 해야 하는 것도 문제
    • 물론 안전성이 매우 높아짐→은행 인터넷 뱅킹에서 사용
  • 클라이언트의 실재만 증명하지, 사용자 본인임을 증명하지 않을 가능성 존재

'야매 증명서'

• 책의 표현을 빌리면 ‘나야 나’ 증명서라고도 부름
• OpenSSL 등의 소프트웨어 사용시 누구든지 인증 기관 구축 가능→서버 증명서 발행 가능
• 독자적으로 구축한 인증 기관에서 발행한 증명서를 가진 사이트(서버)에 접속시 [접속의 안전성을 확인할 수 없습니다.] 등의 경고문 발생
• 브라우저가 식별하지 못하는 인증기관의 증명서를 가진 서버는 다른 서버로 위장하거나 믿을 수 없는 서버임을 암시
• 일부 브라우저에만 포함된 마이너 인증 기관의 증명서도 다른 브라우저에서는 야매 증명서로 취급

 

 

---

 

 

HTTPS 통신 과정

(→)는 클라이언트가 서버로 전달하는 신호를, (←)는 서버가 클라이언트로 전달하는 신호를 의미

1. Handshake: ClientHello (→)

• 클라이언트가 Client Hello 메시지 송신하면서 SSL 통신 시작
• 메시지에는 클라이언트가 제공하는 SSL 버전 지정, 암호 스위트 포함
• 암호 스위트: 사용하는 암호화의 알고리즘이나 키 사이즈 등이 포함된 리스트

2. Handshake: ServerHello (←)

• 서버가 SSL 통신이 가능한 경우 Server Hello 메시지로 응답
• 클라이언트와 동일하게 SSL 버전과 암호 스위트 포함
  • 서버 측에서는 클라이언트한테서 받은 암호 스위트의 내용 중에서 선택된 것을 보냄

3. Handshake: Certificate (←)

• 서버가 Certificate 메시지 송신
• 메시지에는 공개키 증명서 포함

4. Handshake: ServerHelloDone (←)

• 서버가 Server Hello Done 송신
  • 최초의 SSL 네고시에이션 부분이 끝났음을 통지

5. Handshake: ClientKeyExchange (→)

• 서버의 Server Hello Done 메시지에 대해 클라이언트가 Client Key Exchange 메시지로 응답
• 통신을 암호화하는 데 사용하는 Pre-Master secret 포함
• 이 메시지는 3번 과정에서 서버가 보낸 공개키 증명서에서 꺼낸 공개키로 암호화된 상태

6. ChangeCipherSpec (→)

• 클라이언트가 Change Cipher Spec 메시지 송신
• 해당 메시지 이후의 통신은 암호키를 사용해서 진행한다는 뜻

7. Handshake: Finished (→)

• 클라이언트가 Finished 메시지 송신
• 접속 전체의 체크 값 포함
• 서버 측에서 해당 메시지를 올바르게 복호화할 수 있다면 네고시에이션 성공했다는 으미ㅣ

8. ChangeCipherSpec (←)

• 서버 측에서 Change Cipher Spec 메시지 송신

9. Handshake: Finished (←)

• 서버 측에서도 Finished 메시지 송신
• 서버와 클라이언트의 Finished 메시지 교환 완료시 SSL에 의해 접속 확립
  • 통신은 SSL에 의해 보호되는 상태
  • 이제부터 애플리케이션 계층의 프로토콜에 의해 통신 진행(그 전까진 SSL 통신이었음)

10. Application Data(HTTP) (→)

• 9번 과정에 의해 SSL에 의해 보호된 상태로 서버에게 리퀘스트 송신

11. Application Data(HTTP) (←)

• 마찬가지로 리퀘스트에 대한 리스폰스 송신

<10, 11 과정 추가>

애플리케이션 게층의 데이터 송신시 MAC(Message Authentication Code)이라고 부르는 메시지 다이제스트를 붙여 메시지 변조 감지 가능

12. Alert: warning, close notify (→)

• 클라이언트가 접속을 끊기 위해 close_notify 메시지 송신
• 이후에 TCP FIN 메시지를 보내 TCP 통신 종료

 

 

---

 

 

SSL(TLS)의 단점

• 통신 속도 저하
  • HTTP를 사용하는 경우에 비해 2배~100배 정도 느려짐
  • TCP 접속과 HTTP 리퀘스트/리스폰스 이외에 SSL에 필요한 통신이 추가되기 때문
• CPU, 메모리 등의 리소스 다량 소비
  • 암호화/복호화를 위해 리소스 다량 소비
  • 처리 가능한 리퀘스트 수 감소
• →SSL 액셀레이터라는 하드웨어를 이용해 SSL의 처리만 담당시켜 부하 분산

그래서 민감한 데이터를 주고받을 때에만 HTTPS를 통한 암호화 통신을 진행하고, 나머지 요청/응답에 대해서는 HTTP로 통신 진행하는 경우 존재