Jins' Dev Inside

SSL 이란 Security Socket Layer 의 약자로  Netscape에서 서버와 브라우저 간 보안을 위해 만든 프로토콜이다. SSL은 CA(Certificate Authority)라 불리는 서드 파티로부터 서버와 클라이언트의 인증을 하는데 사용된다. 서버와 클라이언트 간의 통신 과정은 다음과 같다.

(1) 클라이언트가 SSL로 암호화된 페이지를 요청한다(https)

(2) 서버는 Public key를 인증서와 함께 전송한다.

(3) 클라이언트는 인증서가 Trusted root CA(인증기관)로부터 서명된 것인지, 날짜 등이 유효한지를 확인한다.

(4) 인증을 확인한 클라이언트는Public key로 URL, http 데이터들과 자신의 대칭키을 암호화하여 전송한다.

(5) 서버는 인증서에 대한 Private key로 요청을 복호화하고 전달받은 대칭키로 응답을 암호화해서 전송한다.

(6) 브라우저는 대칭키로 응답을 복호화해서 사용자에게 보여준다.

 이렇게 대칭키를 공개키 암호화방식으로 암호화해서 전송한 후 대칭키로 통신하는 프로토콜을 SSL 방식이라고 한다.

 이 과정에서 사용되는 서명(Signing)이란 특정 메시지를 작성했다는 것을 인증하는 역할이다. 서명의 과정은 다음과 같다.

(1) 해쉬 생성

(2) Private key로 해쉬 암호화

(3) 암호화된 해쉬와 서명된 인증서를 메시지에 추가

(4) 받는 사람은 따로 해쉬를 생성

(5) 받은 메시지에 포함된 해쉬를 Public key를 이용해서 복호화

(6) 4, 5번 과정에서 생성된 해쉬를 비교한다.

 다음은 이 과정을 정리한 SSL 의 워크플로우를 나타낸 그림이다. 아래의 그림에서 1, 2, 3번 과정은 위의 설명 이전의 과정이 된다.

이처럼 SSL은 공개키로 대칭키를 전달하고 실제 암호화 및 해독 작업은 대칭키로 하여 비용과 안정성 측면에서 이점을 갖는 표준 보안 방식을 말한다. 공개키 암호화 방식은 대칭키 암호화 방식보다 훨씬 안정적이지만 속도가 훨씬 느리다. 

사이트에 대한 인증서 문제는 요청한 사이트가 ‘진짜’ 인지를 인증기관을 통해 검증받기 위해서 생긴다. 인증받은 신뢰할 수 있는 사이트의 경우 SSL 통신이 진행된다. 

CORS(Cross Origin Resource Sharing)

최근에는 대부분의 웹 서버가 REST API 서버를 통해 동작하며, 백엔드 개발자라면 익숙하겠지만 프론트엔드만 담당한다면 당황할 수도 있다. 실제로 처음에 본인도 웹페이지부터 서버 개발에 입문하면서 당황했던 부분이다.

웹사이트는 종종 인터넷 상의 다른 서버에 호스팅된 리소스를 요청하는 경우가 있다. 이때, 서버를 거치지 않고 Browser 단에서 직접 외부 호스트로부터 리소스를 받는 일은 서버의 보안 입장에서 유쾌한 일은 아니며, 호스팅하는 서버 입장에서도 무분별한 요청을 받게 되는 일이다. CORS는 이를 위해 보안정책을 통해 이를 제한하고자 하는 개념이다.

 CORS는 웹페이지가 리소스가 존재하는 다른 도메인으로 요청이 발생하는 것을 제한하는 규칙이다. 브라우저와 서버에서 다른 도메인과 안전하게 연결을 하고자 요청을 제약하는 규칙이다.

 이러한 정책이 생겨나게 된 배경에는 웹서버의 API 적 역할이 강화되었기 때문이다. REST API 를 소개하면서 포스팅하겠으나, 많은 종류의 Web API 는 GET을 제외한 요청들이 데이터를 변경할 수 있게끔 되어 있다. 

그렇기 때문에 GET이 아닌 다음과 같은 요청들의 경우 전처리과정(Pre-flight Request) 라 하여, HTTP 요청을 보내기 전에 먼저 OPTIONS 요청을 보내서 호스팅 서버로부터 확인 작업을 거친다.

 만약 호스팅 서버로부터 인증받은 도메인의 허가받은 요청이라면, 그다음 본 요청으로 리소스를 가져온다.

 - Pre-flight 요청이 선행되는 경우 : PUT , DELETE , CONNECT, OPTIONS, TRACE, PATCH

(POST 요청의 경우 조건적으로 특정 MIME Type에 대한 호출에 대해서 Pre-flight가 선행된다.)

 이는 브라우저에서 쉽게 확인할 수 가 있다. 브라우저는 위와 같이 GET / POST 이외의 요청에 대해 OPTIONS Request를 보내는데, 다음처럼 Origin 이라는 헤더를 Request 에 담아 보내게 되고, 서버 측에서 Response로 Access-Control-Allow-Origin 라는 헤더에 허용된 도메인을 담아 보낸다.

그렇다면 호스팅 서버의 응답 값을 같이 살펴보자

위의 예에서 해당 서버는 example.com 이라는 도메인에서 요청한 PUT, DELETE 메서드만 허용한다. 물론 example.com 에서 요청했기 때문에 위의 요청은 PUT 또는 DELETE 라면 에러를 발생시키지 않고, 해당 PUT / DELETE API 를 요청한다.

 CORS 표준은 서버가 지정한 일련의 도메인 들에 대해 정보를 읽을 수 있도록 허가하는 HTTP 헤더를 추가하여 문제를 해결한다.

 * 일반적으로 서버측에서는 요청들에 대해 Credentials 를 담아 처리하게 하며, 별도로 리소스에 대한 접근을 허용하는 Whitelist 방식으로 처리한다.