회사 자체 서비스(자바 웹 서버) 내에서 타 서버에 HTTP request를 보내야 하는 코드를 작성해본 경험이 있다.
처음부터 구현을 하려면 오랜 시간이 필요했기에 선임 개발자분들이 구현해 놓은 코드를 보고 분석했고, 여기서 요청 메소드를 공통적으로 사용할 수 있도록 분리해 놓은 것을 확인했다.
직접 인터넷 검색과 시행착오를 겪지 않아도 된다는 행복한 마음으로 그대로 사용을 했고, 기억은 잘 나지는 않지만 어떠한 문제로 인해 제대로 된 응답을 받지 못하는 상황이 오게 된다.
다행스럽게도 공통적으로 분리해놓았던 클래스 내에 SSL 예외가 발생할 경우 사용하라는 메소드를 발견했고, 그대로 사용을 해보니 운이 좋게 올바른 응답을 받을 수 있었다.
아마 서버에서 직접 요청을 했을 때나, Postman을 통해 요청을 보냈을 때 SSL과 관련한 키워드가 오류 메세지로 나왔기 때문에 내가 해결할 수 있었던 것 같다. 그렇지 않고서는 SSL이라는 것이 뭔지도 몰랐던 내가 해결할 수 없었을 것 같다.
당시에는 구현에만 급급했다.
문제의 원인이 무엇인지 파악하지 못했다.
해결을 했으나 어떻게 해결했는지 몰랐다.
SSL이라는 키워드가 무엇인지도 모르고 많은 시간이 흘렀다.
SSL이라는 것을 알아야만 해결 가능했던 문제였으면, 나는 과연 어떻게 해결을 했었을까?
SSL이라는 키워드와 관련한 오류라는 것조차 파악하지 못했다면 나는 당시에 그것을 구현할 수 있었을까?
SSL과 관련한 문제였다는 것을 파악했더라도, 이 문제를 해결한 메소드가 미리 구현되지 않았더라면 내가 직접 만들 수 있는 역량이 있었을까?
다양한 생각들이 떠오르며, 언젠가는 이 SSL이 뭔지 알아내야겠다는 생각이 마음속에 있었고, 이제서야 이것이 무엇인지 알아볼 것이다.
이것을 알게 되면, 응답을 받아오지 못했던 이유와 해결했던 방법을 알 수 있을 것 같다.
깊게 들어가면 끝도 없으며, 하나의 개념을 알기 위해서는 포함된 다른 여러 가지 개념들을 알고있어야 하기 때문에 검색을 하여도 다른 사람들이 올린 글 중에 명확하게 공통적으로 기술해놓은 어떤 기준이 없었다.
나 또한 여러 자료들을 통해 나름대로 정리를 해보게 되었다.
SSL(Secure Socket Layer) 이란?
SSL은 네트워크로 연결된 컴퓨터 간에 인증 및 암호화된 링크를 설정하기 위한 프로토콜이다.
개발은 Netscape에서 웹서버와 브라우저 사이의 보안을 위해 만들었다.
이렇게 만들어진 SSL이 인터넷 보안 영역에서 표준화가 되어가면서 국제 인터넷 표준화 기구에서 SSL이라는 명칭이 특정 회사의 제품 이름 같다고 하여, TLS(Transport Layer Security)로 표준화하였으며, SSL 3.0이 TLS 1.0 버전의 기초가 된다.
이렇게 이름을 바꿨으나, TLS라는 용어보다 SSL이라는 용어로 많이 소개가 되고 있다.
SSL의 특징
SSL 암호화 통신은 비대칭키 방식으로 암호화에 사용할 키를 교환하고, 대칭키 방식으로 데이터 통신을 한다.
SSL은 왜 사용하는가?
기존에 인터넷 공간에서 주고받던 통신 프로토콜인 HTTP는 네트워크상의 패킷은 스니퍼(Sniffer)에 의해 도청당할 수 있다.
이런 것을 방지하기 위해 HTTP프로토콜에 SSL, TLS 를 얹어 통신을 한다.
이런 SSL,TLS은 HTTP뿐만 아니라 FTP, SMTP와 같은 다른 프로토콜에서도 적용할 수 있다.
이렇게 보안계층을 사용하여 보호하게 되면 HTTP가 HTTPS (HTTP + Secure)가 되는 것이고, 검색을 해보니 실제로 SMTPS, FTPS도 위와 같이 뒤에 S가 붙게 된다.
SSL 인증서
SSL 인증서는 클라이언트와 서버 사이 통신을 제3자가 보증해주는 전자화된 문서다.
클라이언트가 서버에 접속한 직후에 서버는 클라이언트에게 인증서 정보를 전달하게 된다.
클라이언트는 이 인증서 정보가 신뢰할 수 있는 것인지를 검증한 후에 다음 절차를 수행하게 된다.
CA (Certificate authority)
CA는 어떤 사이트가 신뢰가 가능한 사이트인지 보장하는 역할을 해준다.
서비스를 제공하는 회사들은 자신들의 사이트에 대한 자료와 공개키를 CA에 보내고 CA는 해당 자료들의 검토를 마친 후, 사이트 정보와 공개키를 인증기관의 비공개키로 암호화한다. 이 암호화된 정보가 사이트 인증서이다.
따라서 SSL을 통해서 암호화된 통신을 제공하려는 서비스는 CA를 통해서 인증서를 구입해야 한다.
chrome, safari 등 각각의 브라우저에는 공인된 CA 리스트와 각 CA의 공개키가 탑재되어 있다.
만약 직접 사용하는 개발 서버나 사내 서버의 경우, 이미 사이트의 신뢰가 확보되어 있기 때문에 굳이 인증서를 사용하지 않아도 된다
SSL과 OSI 7계층
SSL(Secure Socket Layer)을 한국어로 풀어보면 보안 소켓 계층을 뜻한다.
계층이라는 말을 듣자마자 OSI 7계층 모델이 떠오른다. 머릿속은 학창 시절로 돌아가 물데네전세표응을 떠올리지만, 보안 소켓 계층은 어디에도 없다.
SSL은 OSI 7계층 모델의 어느 한 계층에 속해서 동작하는 것이 아니라, 응용계층과 전송계층 사이에 독립적인 프로토콜 계층을 만들어서 동작한다. 응용계층의 프로토콜들은 외부로 보내는 데이터를 TCP가 아닌 SSL에 보내게 되고, SSL은 받은 데이터를 암호화하여 TCP에 보내어 외부 인터넷으로 전달한다.
전달받을 때 역시 TCP로부터 받은 데이터를 복호화하여 응용계층에 전달하게 되는데, 이 과정에서 Application은 SSL을 TCP로 인식하고, TCP는 SSL을 Application으로 인식하기 때문에 Application과 TCP 사이의 데이터 전달 방식은 기존 전달 방식을 그대로 사용하게 된다.
SSL 보안 적용 과정
먼저 통신의 과정을 알아야 한다. 통신의 과정은 총 세 단계로 나눌 수 있다.
핸드셰이크 → 전송 → 종료
SSL 핸드셰이크를 수행한다. 데이터를 주고받기 위해 어떤 방법을 사용해야 하는지 서로의 상태를 파악한다. 서로 간의 협상이 완료가 된다면, SSL 세션이 생성되고 클라이언트와 서버는 서로 원하는 데이터를 주고받게 된다. 이후 데이터 전송의 끝을 서로에게 알리며 세션을 종료한다.
위는 요약한 내용이고, 핸드셰이크 내부에도 수많은 단계로 나뉘어 있으며, 인터넷에 찾아보면 또한 많은 자료가 존재한다.
그래서 SSL이 무엇인지 알게 되니 당시에 어떤 오류로 인해 응답이 오지 않았던 것인지 알았는가?
그리고 어떻게 해결한 것인지 파악했는가?
결론부터 말하면 둘 다 아직도 정확하게 알지 못했다.
추측만으로 한가지의 결론을 내리는 것은 위험하다.
그래도 어떤 문제였는지 가장 정답과 근접한다고 생각하는 것과 그렇게 생각하는 이유가 있다.
요청 보내는 서버 쪽 SSL 인증서가 유효하지 않다. 만료되었거나, 오류가 있다. 이런 문제 때문에 일반적인 요청으로는 제대로 된 응답을 받을 수 없는 것 같다. 이것이 내가 생각한 추측이다.
이유는 다음과 같다. 내가 요청했던 타 서버는 동일한 도메인네임과 포트번호에 JSON 데이터 응답만을 주는 디렉토리가 아닌, 어떤 테스트 화면을 제공해주기 위해 HTML 문서를 응답하는 디렉토리가 존재한다. 그리고 그것을 이용하기 위해 내가 브라우저로 접속했을 때 인증서 관련 오류로 인해 웹페이지가 바로 보이지 않았던 기억이 있다.
글을 작성하며 다시 브라우저로 접속해 보니 아직도 이런 메세지와 함께 웹페이지가 바로 보이지 않는다.
어떻게 해결을 했는지는 어떤 오류인지도 명확하게 파악하지 못하니 알 수 없다.
대충 이럴 것이다. 라고만 생각할 뿐이다.
찝찝한 기분을 지울 수 없다.
나는 선임 개발자님이 짜놓은 SSL 예외를 무시하는 메소드를 사용해 해결을 하였으나, 이 메소드에 작성된 코드가 일반적인 HTTP 요청과 어떤 특별한 다른 점이 있는 것인지 모른다.
이것 역시 추측만 있을 뿐이다. 사용했던 메소드를 분석해봐도 이해하지 못하기 때문에 확신이 없다. 그러니 근본적인 문제의 원인도 모르고 해결한 방법도 모른다.
난 무엇을 한 것일까?