레이블이 SSL인 게시물을 표시합니다. 모든 게시물 표시
레이블이 SSL인 게시물을 표시합니다. 모든 게시물 표시

2018-02-22

Cloudflare의 Flexible SSL을 쓰면 안 되는 이유

 Cloudflare의 서비스 중 Flexible SSL이라는 것이 있다. SSL 인증서가 없는 서버에 있는 웹페이지도 https를 이용해 접근할 수 있도록 해주는 서비스다. 자신이 인증서를 설치할 수 없는 서버나 서비스를 사용할 때도 https를 사용할 수 있게 해주기 때문에 blogger처럼 커스텀 도메인에 https를 지원 안 하는 서비스를 이용하는 사람들이 많이 사용한다. 이 블로그도 blogger에서 custom domain을 이용하고 있기 때문에 https를 지원하려면 Cloudflare의 Flexible SSL이 사실상 유일한 옵션이다. 하지만 https를 포기하고 Flexible SSL을 사용하지 않고 있다. 왜냐하면, Flexible SSL이 아무런 이득이 없는, 오히려 위험하기만 한, 존재해서는 안 되는 서비스이기 때문이다. Flexible SSL을 엄청 디스한 것 같은데 어째서 그런지 Flexible SSL이 동작하는 방식을 보면 쉽게 이해할 수 있다.

 위의 도표는 Flexible SSL이 어떻게 동작하는지를 그림으로 표현한 것이다. Cloudflare의 DNS는 요청된 도메인에 대해서 원래 서버의 주소를 주지 않고, Cloudflare 서버의 주소를 준다. 그러면 클라이언트의 브라우저는 원래 서버가 아닌 Cloudflare의 서버로 접속한다. 그러면 Cloudflare의 서버는 원래 서버로 다시 요청을 보내고, 받은 결과를 클라이언트에게 돌려준다. 이때 클라이언트와 Cloudflare 사이의 통신은 암호화된 https로 이루어지고, Cloudflare와 원래 서버 사이의 통신은 암호화되지 않은 http로 이루어진다.

 이를 보고 "최소한 Cloudflare와 클라이언트 사이에는 https를 사용하기 때문에 안전하지 않은가"라고 생각하는 사람도 있다. 하지만 아니다. 보안에서 자주 사용되는 격언에 "A chain is only as strong as its weakest link."라는 말이 있다. 어떤 시스템이 해킹당할 위험도는 그 시스템을 구성하는 요소 중에서 가장 취약한 요소가 해킹당할 위험도와 같다는 말이다. 설령 클라이언트와 Cloudflare 사이의 통신이 암호화됐다고 해도, Cloudflare 서버와 원본 서버 사이의 통신이 암호화됐지 않았기에 Man-in-the-middle attack을 당해 조작된 페이지를 받거나 요청된 데이터가 해킹당할 위험도는 Cloudflare 서버를 통하지 않고 원본 서버와 바로 http로 통신했을 때와 같은 위험도를 가진다.

 사실 Flexible SSL은 사용 안 하는 것보다 더 위험하다. Flexible SSL을 사용하지 않으면, 기본적인 지식이 있는 사용자라면 지금 페이지가 안전한 페이지인지 판단하여 민감한 정보를 보낼지 말지 결정할 수 있다. 하지만 Flexible SSL을 이용하면 모든 페이지가 암호화된 것처럼 보이기 때문에 사용자가 안전한 페이지인지 판단할 수 없다. 게다가 최신 브라우저의 경우 보안을 위해서 안전하지 않은 페이지와 안전한 페이지를 자동으로 구분해서 https 페이지에서 http 페이지로 데이터를 보내거나 http 페이지에서 콘텐츠를 가지고 오는 것을 막는다. 하지만 Flexible SSL을 사용하면 이런 기능을 전혀 이용할 수 없다.
 따라서 Flexible SSL을 사용하면 해킹 위험도는 그대로 가져가면서, 오히려 브라우저의 보안 기능을 못 사용하게 될 수 있기 때문에 더 위험해질 수 있다. 특히나 사용자에게 위험도를 속인다는 점에서 Flexible SSL을 사용하면 사용자를 기만하게 된다고 말할 수 있다.


이 글을 쓸 때는 몰랐는데 작년 12월에 이미 blogger도 custom domain에 대한 https 지원을 시작했었다. 올해 계속 바빠서 확인을 제대로 못 했던 것은 있는데, 이 정도 변화면 레딧이든 해커 뉴스든 어디선가 관련된 글이 올라왔을 것 같은데 왜 못 보고 넘어갔는지 모르겠다.

2014-07-03

WeeChat에서 SSL 사용하기

 지금까지 irc 클라이언트로 irssi를 쓰고 있었다.
 irssi의 기능이나 여기서 제공해주는 스크립트들에 불만이 있는 건 아니지만, perl 스크립트만 support 한다는 것이 결국 문제가 되어(원래 계획은 이 기회에 perl을 배운다는 것이었는데 굳이 irc하나 때문에 perl을 새로 배우는건 손해처럼 보였다.) WeeChat으로 갈아타기로 했다.

 WeeChat은 irssi와 매우 비슷한 look and feel의 UI를 가졌지만, extensible 하다는 것을 장점으로 내세우며 Perl은 물론이고 Lua, Ruby, Python같은 유명한 스크립트 언어들이나 TCL, scheme 같은 교육용으로 자주 쓰이는 언어까지 지원해준다.
 게다가 irssi에서 많이 쓰이는 스크립트(trackbar, nickcolor 등)은 builtin기능으로 제공해 주고, 선택할 수 있는 configuration들도 irssi보다 많다.

 다양한 스크립터언어의 지원이 마음에 들어서 WeeChat으로 옮기기로 했지만, 너무 많은 configuration이 있는 것 때문에 설정하는 게 irssi보다 복잡하다.

 이하 SSL을 사용하기 위해 삽질한 내용들이다.
 WeeChat의 기본 설정 값은 ssl을 사용하지 않아서 따로 사용하도록 설정해 줘야 한다.

 문제는
/set server.ssl = on
을 해줘도 ssl을 사용해서 freenode채널에 접속할 수 없다.
 이에 대해서는 WeeChat FAQ에 해결책이 나온다.
 WeeChat에서는 irssi와는 다르게 Diffie-Hellman key의 길이를 설정해 줄 수 있는데, WeeChat의 기본값은 2048이고 freenode에서 사용하는 key size는 1024다.
/set server.ssl_dhkey_size = 1024
 도 해줘야 한다.

 freenode는 워낙 유명한 채널이라서 FAQ에도 나와있고 금방 해결되었다.
 문제는 국내에서 많이 쓰이는 urric라는 서버에서도 SSL 인증서의 문제로 hand shake가 실패했다고 나오는데, uriirc사용자 중에서 weechat 사용자가 얼마 없는지 이에 대해 해결하는 방법은 나와있지 않았다.
 uriirc 서버의 SSL인증서가 가지는 문제는 크게 3가지이다.

  1. diffie-Hellman key size가 1024이다.
  2. 인증서가 기한 만료되었다.
  3. 인증서의 hostname이 irc.uriirc.org가 아니다.
 key size는 위와 같은 방법으로 해결하면 되는데, 공식적으로 관리되는 서버가 아니라서 그런지 인증서에 이래저래 문제가 많다.
 WeeChat 매뉴얼을 읽어보니 WeeChat은 기본적으로 SSL verify기능이 켜져있고, configuration을 통해서 꺼야한다.
 따라서
/set server.ssl_verify = off
를 해야 한다.

 irssi에서도 SSL verify 기능이 있지만, 이쪽은 default가 off라서 irssi로 접속할 때는 SSL 인증서에 문제가 있는지 모르고 써왔던 것이다.

 초기 세팅을 위해 검색하느라 시간을 조금 쓰기는 했지만, 이것저것 설정해줘야 해서 조금 더 안전하게 사용할 수 있는 것 같은 착각(?)이 든다.