tech.junha.kr

HTTP / HTTPS 동작 원리를 살펴보자

1. 어떤 보안 위험이 있다는 거지?

첫 째: 개인정보가 담긴 정보를 서버로 보낼 때, 어떤 놈이 갈취해갈 수 있음
둘 째: 피싱 사이트에 접속해 개인 정보를 갈취해갈 수 있음

HTTPS는 사이트에 보내는 정보를 제 3자가 보지 못하게 하며, 접속한 사이트가 믿을 만한 사이트인지 알려준다.

2. HTTPS를 이해하려면

1) 대칭키 방식: 암호화에 쓰이는 키와 복호화에 쓰이는 키가 동일한 기법

클라이언트와 서버가 대칭키 방식으로 통신을 한다면 클라이언트, 서버 모두 키를 가지고 있어야한다.

하지만 애초에 클라이언트에게 키를 전달하는 것 자체도 위험하며, 또한 클라이언트의 스코드는 누구든지 열어볼 수 있으므로 가지고 있기도 굉장히 위험하다. 즉, 원거리에서 대칭키를 안전하게 전달하는 것이 매우 어렵다.

2) 비대칭키 방식: 공개키와 비밀키를 사용하는 기법

공개키: 누구나 획득할 수 있는 공개된 키. 클라이언트는 이 키를 가지고 데이터를 암호화해서 전송한다.

개인키(비밀키): 공개키로 암호화된 데이터를 복호화 할 수 있는 키. 서버만 가지고 있다.

이 방법은 안전하게 데이터를 주고받을 수 있지만, 속도가 느리다는 단점이 있다!

3) 인증서와 CA(Certificate authority)

인증서의 내용은 크게 2가지로 구분한다.

  1. 서비스의 정보 (CA, 도메인 등등)
  2. 서버 측의 공개키 (공개키의 내용, 공개키의 암호화 방식)

CA는 인증서를 발급해주는 기업을 말한다. 인증서가 보안에 관련된 것인 만큼 이 CA는 영향력있고 신뢰할수 있는 기업에서만 가능하다. 이때, 브라우저에는 공인된 CA 리스트 미리 가지고 있다.

2. HTTPS 통신과정 및 원리

HTTPS는 대칭키 방식과 비대칭키 방식 모두 사용한다.

모든 데이터 전송을 비대칭키 방식으로 일일이 암호화 복호화려면 컴퓨터에 부담이 커진다.

따라서 비대칭키 방식으로 대칭키를 안전하게 전달하고, 전달된 대칭키로 데이터를 주고 받는다.

1) 전체적인 과정

1. HandShake

클라이언트는 랜덤 데이터를 생성하여, 서버로 보낸다.

서버는 답변으로, 랜덤 데이터와 인증서를 보낸다.

2. 서버로부터 받은 인증서 확인

브라우저에 내장된 CA들의 정보로 인증서의 진위여부를 파악한다.

우선, CA의 인증을 받은 인증서들은 CA만 갖고있는 개인키로 암호화 되어있다.

서버로부터 받은 인증서가 진짜라면, 브라우저에 있는 CA의 공개키로 복호화 할 수 있을 것이다.

공개키로 복호화 될 수 있는 인증서를 발급할 수 있는 건 개인키를 가진CA 뿐이니깐!

만약, CA 리스트 중에 인증서가 해당되는 게 없다면 브라우저 주소창에 HTTPS 인증 실패가 뜬다.

복호화에 성공되었다면, 서버의 공개키가 포함돼있다.

3. 대칭키 생성

클라이언트에서 생성한 랜덤 데이터, 서버에서 성생한 랜덤 데이터를 혼합해서 임시키를 만든다.

임시키는 서버의 공개키로 암호화돼서 서버로 보내진다.

이 임시키는 양쪽에서 일련의 과정을 거친 후, 동일한 대칭키가 된다.

이제 이 대칭키는 서버와 클라이언트 둘만 갖고 있기 때문에, 이후 서로 주고받는 데이터는 제 3자가 들여다 볼 수 없다.

2) 상세 과정

  1. Client Hello

브라우저마다 지원하는 암호화 알고리즘과 TLS 버전이 다르므로 해당 정보를 전송하며, 난수 값을 생성하여 전송합니다.

  1. Server Hello

사용할 TSL 버전, 사용할 암호화 알고리즘, 난수값을 전송합니다.

  1. Certificate

CA로 부터 발급받은 인증서를 전송합니다.

  1. Server Key Exchange

키 교환에 필요한 정보를 제공합니다. 만약 필요하지 않으면 이 과정은 생략이 가능한데, 예를 들어 키교환 알고리즘을 Diffie-Hellman으로 사용한다면 소수, 원시근 등이 필요하므로 이것을 전송합니다

  1. Certificate Request

서버가 클라이언트를 인증해야할때 인증서를 요구하는 단계입니다. 요청하지 않을수도 있습니다.

  1. Server Hello Done

  2. Client Key Exchange, Change Cipher Spec

pre-master-key 라는 것을 전송합니다. 이 키는 1,2 단계에서 생성한 난수를 조합하여 생성하게되며 대칭키로 사용하게될 예정입니다. 그러므로 안전한 전송을 위해서 공개키 방식을 사용하여 전송합니다.

  1. Change Cipher Spec

클라이언트로 부터 전송받은 pre-master-key를 정상적으로 복호화 후 master-key(대칭키)로 승격 후 보안 파라미터를 적용하거나 변경될때 보내는 알림입니다.

위 과정을 통해서 공개키 방식으로 대칭키를 안전하게 설정하여 데이터를 송, 수신하게됩니다.

각각의 방식의 장점을 사용하여 단점을 보안한 케이스입니다.

3. HTTPS는 SEO에 유리하다

검색 포털 사이트인 구글, 네이버, 다음 모두에서 검색 엔진 최적화 SEO : Search Engine Optimization)를 통해 https를 상위노출 하고 있다. 동일한 키워드의 페이지 중에서 https 기반의 사이트가 우선 순위로 노출된다. 보다 안전하다고 판단되는 사이트에 가산점을 준다.

출처: https://mysterico.tistory.com/30