Written by glqdlt
on 

HTTPS 웹 서비스

HTTPS

HTTPS 는 HTTP 웹 프로토콜에 TLS(SSL) 를 적용함으로써 보다 안전한 웹 서비스를 이용할 수 있는 수단이다. 최근 브라우저들은 모든 기능에서 HTTPS 가 있어야만 동작하는 개념으로 바뀌어 가고 있다. 특히 최신 모바일OS 브라우저들은 HTTPS 로 되어 있지 않는 웹 서비스에 접근하려 하면 처리가 되지 않는 경우도 있다. 심한 경우 <a> 태그나 <img> 태그처럼 외부 리소스를 참조하는 태그조차 외부 리소스가 HTTPS 서비스가 아니여도 동작하지 않는 경우가 있다. 웹 페이지를 전송해주는 서버는 HTTPS 구성이지만 웹 페이지 내부 참조 링크가 HTTP 일 때의 경우를 ‘혼합컨텐츠(mixed https)’ 라고 부른다.

크롬 브라우저의 경우 현재 실험실 기능(크롬에서 chrome://flags 입력) 으로 브라우저 주소 창에 example.com 이라고 친다면, 과거에는 http://example.com 으로 접속했으나, 최근 버전부터는 https://example.com 으로 우선시 해서 접속을 시도한다.

HTTPS 는 이제 선택이 아닌 표준으로 자리잡아가고 있기에 이에 대한 메카니즘을 확실히 이해하는 것이 중요해졌다.

대칭키 와 비대칭키

HTTPS 는 대칭키와 비대칭키 암호화 개념이 모두 적용되어 있다. 따라서 이에 대한 이해도 필요하다.

대칭키와 비대칭키의 차이점은 암/복호화에 사용되는 키가 똑같냐 다르냐를 의미 한다. 대칭키는 암호화하고 복호화하는 데에 사용되는 키가 동일하나 비대칭키는 암호화하는 데에 쓰이는 키와 복호화하는 데에 사용하는 키가 서로 상이하다. 비대칭키는 두 키 중에 하나는 암호화하는 데에만 사용이 되고, 다른 키는 복호화하는 데에만 사용이 된다.

일반적으로 비밀키(secret key 또는 private key) 라고 칭하는 키를 복호화에 사용하는 키로 사용하고, 공개 키 (public key)라고 하는 외부에 알려져도 되는 키를 암호화하는 데에 사용한다.

공개키 알고리즘은 RSA 알고리즘이 대표적이다. 이름이 RSA 인 것은 만든 사람들의 이니셜을 따왔는데, RSA(Ron Rivest, Adi Shamir, Leonard Adleman) 이다.

HTTPS 의 SSL(TLS) 통신은 대칭키와 비대칭키가 섞여 있는 하이브리드 방식이다. 왜 하이브리드인지는 HTTPS 가 맺어지는 과정을 이해하면 알수 있다. 개인적으로는 매우 흥미로워서 무릎을 탁 칠수밖에 없더라.

HTTPS 핸드쉐이킹

  1. 웹서버가 유저 브라우저에 TLS 인증서를 전달한다. 인증서에는 서명정보와 공개키가 포함되어 있다.

  2. 브라우저에서 서명정보를 통해 신뢰가능한 인증서인지 검토한다. 이후 웹 서버의 공개키를 추출해서, 해당 공개키의 출처인 인증서 발급소에 해당 키가 합법적인 키인지 확인한다.

  3. 브라우저에서는 암호화/복호화에 같이 사용할 대칭키를 생성한다. 이후, 웹서버의 공개키로 이를 암호화한다.

  4. 브라우저는 암호화된 대칭키를 웹서버로 전송함

  5. 웹서버는 자신만 알고 있는 인증서의 비밀키로 암호화된 대칭키를 해동해서, 대칭키를 추출한다.

  6. 이제 유저 브라우저와 웹 서버는 서로 같은 대칭키를 공유하게 되었다.

  7. 이후 모든 통신의 패킷에는 대칭키로 암호화되어 브라우저와 웹서버만이 알고 있는 대칭키로 해독이 가능하다.

인코딩(encoding) 과 암호화(encrypt)

신입 시절에 다녔던 기업에서의 일화이다. 어떠한 목적으로 외부 아웃소싱 회사와 협업을 할 때였는데, 아웃소싱의 개발자의 소스를 인계 받아서 분석해야할 일이 있었다. 소스와 운영 데이터를 보다가 유저의 패스워드를 BASE64 로 인코딩 되어있길래, 어떠한 이유로 인코딩했냐고 질문을 한 적이 있다. 돌아온 대답은 ‘아~ 아직 연차가 작으셔서 잘 모르시는 가 보구나, 이거 암호화한거에요~ 암호화’ 라고 하더라. 한국 SI의 현실이구나 싶었다.

인코딩

인코딩과 암호화는 사전적 의미에서 조차 완전히 다르다. encrypt 는 암호화라는 의미이고, encode 는 인코딩이라 한다. 인코딩이라는 개념은 정보의 형태나 형식을 어떠한 포맷으로 변환하는 개념을 말한다. 위키에 잘 설명되어있는 데, 부호화 형태나 형식을 표준화, 보안, 처리 속도 향상, 저장 공간 절약을 위해 다른 형태나 형식으로 변환하는 방식을 말한다. 한자로는 부호화라고 한다. 인코딩은 영상 편집에서도 심심치 않게 볼수 있는 단어로, 웹 서비스에서 문자 인코딩도 다를 바 없이 같은 개념을 가진다.

이미지/영상 편집에서 인코딩은 픽셀을 특정한 포맷으로 압축을 한다는 걸 의미 한다. 예를 들어 RAW 이미지 / 영상의 용량이 100MB 라면, 인코딩을 통해서 용량일 50MB 로 줄일 수 있다. 이미지/ 영상 편집에서 인코딩은 원본 영상과 유사한 화질로 떨어트리되 용량을 획기적으로 줄일 수 있는 알고리즘을 적용한다. JPEG 인코딩을 예로 들면, BMP 원본 이미지를 JPEG 로 바꿧을 때 10MB BMP 이 500kb JPEG 로 바뀌는 기적을 보여준다. 자세히 보면 JPEG 원본에 비해 살짝 흐릿하게 보이는 데, 원본 이미지 픽셀 데이터를 날려버리고 그와 유사한 데이터로 치환시켜버리기 때문이다. 예를 들어서 우리가 “가나다라마바사아” 라는 문자가 있다고 가정하고, JPEG 인코딩처럼 길이(용량)을 줄이는 알고리즘을 적용한다고 생각해보자. 우리는 2글자씩 글자를 그룹핑 하고, 원본 데이터를 의미하는 규칙을 정해서 압축을 시켜보자. ‘가나’는 ‘간’, ‘다라’는 ‘달’, ‘마바’는 ‘맙’, ‘사아’ 는 ‘상’ 이라고 줄여보았다. 보면 알겠지만, 1번째 글자는 원본을 쓰고 2번쨰 글자는 자음을 받침으로 땡겨버렸다. 이렇게 되면 ‘가나다라마바사아’ 는 ‘간달맙상’ 으로 8글자에서 4글자로 절반이나 줄일수 있게 된다. 설명이 어거지 갔지만 이해만을 위한 목적에서는 도움이 되리라 생각한다. 이러한 걸 encode, 부호화 라고 한다.

마찬가지로 웹 서비스에서 자주 등장하는 문자열 인코딩도 어떠한 규칙을 통해 문자로 해석하겠다고 하는 것을 의미 한다. 웹 서비스에서 인코딩이 중요한 것은, 현재는 UTF-8 유니코드를 통해 대부분의 OS 에서 지원을 하기에 만국 공통 문자 인코딩처럼 사용되지만, 과거에는 컴퓨터 마다 문자 인코드가 다 달라서 같은 문자를 얘기하더라도 각기 다르게 해석을 해버렸다.

우리가 컴퓨터에서 보는 문자는 엄연히 따지고 보면 0과 1로 이루어진 이진 데이터(bit)이다.

‘안녕’ 이라는 문장을 A 컴퓨터에서는 0001 이라고 작성한다면, B 컴퓨터에서는 0020 라고 작성 한다. 똑같이 ‘잘가’ 라는 문장은 A에서는 0020 B에서는 0001 이라고 쓰는 규칙이 있다.

이런 환경에서 A에서 0001 데이터를 B 에게 주었을 떄에는 ‘안녕’이 아니라 ‘작별’로 해석하게 된다. 인사도 건내기 전에 헤어지자는 의미로 해석되어버린다.

이런 문제 때문에 A에서 0001 데이터를 B에게 주면서, 이는 A에서 작성을 했어.. 또는 A의 문자인코딩으로 작성 된 데이터야 라고 표기를 해서 B에게 건내어 준다. B는 아~ 이게 A식으로 작성한거니깐 ‘작별’ 이 아니라 ‘안녕’ 이라고 해석해야 하는 구나로 이해하게 되는 것이다.

암호화

암호화의 특징은 관점에 따라서 복호화할수도 없을수 있고, 복호화할수도 있다. 어떠한 이야기냐면, 인코딩은 효과적인 공유를 위한 압축 개념이기에 키라는 개념없이 순수 알고리즘으로만 동작한다. 반면 암호화는 전달 대상(또는 소유자)만에게만 의미를 전달하는 목적으로 쓰이기 때문에 암호키라는 개념을 적용해서 암호키가 없다면 원본으로 복호화가 불가능한 것을 목적으로 한다. 따라서 이 암호키 라는 개념의 유무로 인코딩과 암호화는 확실하게 차이가 나는 부분이라고 볼수가 있다.