Skip to content

Instantly share code, notes, and snippets.

@lifthrasiir
Last active July 30, 2019 13:15
  • Star 34 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
Star You must be signed in to star a gist
Save lifthrasiir/0568ca0c24b500c0253f1d61a23773e3 to your computer and use it in GitHub Desktop.
"구글, 'https' 채택 안한 누리집에 안전하지 않은 곳 '낙인'" 기사에 대한 의견

아래 메일은 2017-02-12 21:43(이하 한국 표준시)에 한겨레 기사에 대한 의견으로서 기사에 제시된 김재섭 기자의 메일로 보낸 내용이다. 메일에서 사실 관계 등의 오류가 있다면 모두 나의 실수이다.

2017-02-13 14:53에 덧붙임: 더 이상 gist를 비공개로 할 이유가 없어졌으므로 공개로 전환. 이 메일에 대한 답변은 받았으나 공개할 만큼 중요한 반론이 들어 있진 않으며 공개 여부도 묻지 않았으므로 공개하지 않는다. 아래 글 자체에도 다양한 비문과 오자가 있으나 본래 보낸 내용을 살리기 위해 전혀 수정을 하지 않기로 했음을 양해 바람.

2017-02-13 19:00에 덧붙임: 이 기사의 후속으로 구글코리아 측의 기자간담회가 올라갔다. 새 기사에 대해서는 특이한 게 없으므로 노코멘트. 또한 위의 기사 링크를 미디어다음에서 한겨레 웹사이트로 가도록 수정.

원문

안녕하십니까, 귀하께서 작성하신 (물론 저는 그 진위를 알 수 없습니다만, 적어도 그렇게 나와 있는) 기사에 대한 의견을 제기하고자 메일을 씁니다. 이 메일은 저의 개인 의견이며 저를 고용하고 있는 회사나 단체 등의 의견을 전혀 대변하지 않음을 혹시나 싶지만 미리 밝혀 둡니다.

구글이 단지 ‘https’ 방식을 채택하지 않았다는 이유로 멀쩡한 누리집에까지 보안상 안전하지 않다는 낙인을 찍어 논란이 일고 있다. 인터넷 보안 수준을 높이려는 노력으로 볼 수도 있지만, 너무 일방적이어서 부작용이 크다는 지적도 나온다. [...]

이 기사는 https가 http와 양립이 가능하다는 기본 전제를 깔고 논지를 전개해 가고 있습니다. 이는 매우 잘못된 시각이며 기술적으로 하자가 없는 내용을 담아야 할 주요 언론지의 기사가 이런 터무니 없는 오류를 담고 있다는 것만으로도 비판받아 마땅합니다.

HTTP, 하이퍼텍스트 전송 프로토콜은 1989년에 팀 버너스 리가 처음으로 월드 와이드 웹을 제창할 때부터 지금까지 구조적으로 크게 달라지지 않았으며, 물론 당시에는 보안 관련된 부분이 전혀 고려되지 않았습니다. 한편으로는 월드 와이드 웹이 인터넷의 근간이 되며 상업적으로 크게 성공하면서 성능에 대한 요구사항이 많아졌는데 기존 HTTP의 형태로는 이를 구현하기 까다롭다는 것이 잘 알려져 있었습니다. (기술적인 부분에 대해서는 말을 아끼겠습니다만 여기에 대한 모범 사례[best practice]가 웹 개발자로서 기본으로 받아들여지는 시기가 있었습니다.)

HTTPS는 1994년(숫자에 주목하십시오. 지금으로부터 23년 전에 만들어졌습니다!)에 당시 잘 쓰이던 넷스케이프 브라우저에서 전자상거래를 위해 SSL 프로토콜(오늘날의 TLS)을 만든 뒤 여기에 HTTP를 결합한 것입니다. 몇 차례 부침이 있었습니다만 (특히 보안성 관련해서 여러 버그가 발견되었고 고쳐졌습니다) HTTPS는 업계 표준으로 받아들여져서 "보안성이 요구되는 곳에서는 HTTPS, 그렇지 않은 곳에서는 HTTP를 쓴다"는 것이 2000년대 쯔음에는 일반화되어 있었습니다.

이제 문제의 스노덴 사건이 2013년에 터집니다. 워낙 유명하니 자세히 쓰진 않겠습니다만, 이 사건으로 인한 다양한 부수 결과 중에 하나는, 기존에도 이런 시각이 제법 있었습니다만 과거에는 보안성이 그걸 요구하는 일부 응용에 한정되었다면, 이제는 민간의 모든 통신에 보안성이 필요하다(왜냐하면 국가 수준의 공격자[state-level adversary]가 존재하며 잘만 활동하고 있는 것이 확인되었으므로!)는 것이 대부분의 IT 업계에 급속하게 퍼집니다. 그러나 기존의 HTTPS는 모두에게 값싸게 보안성을 제공하는데 실패해 왔다는 문제점을 가지고 있었고, 몇 해 만에 다음과 같은 대책이 마련됩니다.

  1. HTTPS/TLS를 운용하려면 인증서가 필요한데 인증서는 그간 돈이 많이 들었습니다(보통 도메인보다 몇 배에서 몇 십배 비쌌습니다). 이에 전자 프론티어 재단(EFF)에서 인증서를 자동으로 무료 발급할 수 있는 인프라를 만들게 되었는데 이것이 Let's Encrypt입니다. 오늘날 Let's Encrypt로 발급된 인증서는 2천만개에 달하며 주요 인증서 발급자로 부상했습니다.

  2. 선술했던 HTTP의 성능 문제를 해결하기 위해서 HTTP/2라는 표준이 느릿느릿하게 만들어지고 있었습니다. 그런데 스노덴 사건이 HTTP/2의 표준화 직전에 일어났기 때문에, HTTP/2에 HTTPS를 무조건 쓰게 하여 암호화를 프로토콜에서 뺄 수 없게 하자는 토론이 크게 일어났습니다. 결과적으로 설계에서는 암호화가 강제가 되지는 않았지만 대부분의 구현자들이 암호화가 안 되어 있으면 HTTP/2를 쓰지 못 하게 했기 때문에 사실상 강제가 된 상황입니다. 한편으로 설계자들이 스노덴 사건을 의식하고 있었음은 HTTP/2 표준에 숨겨져 있는 "PRISM"이라는 감시 프로그램의 이름에서도 드러납니다. [1] 이런 조치가 모두에게 환영을 받은 것은 아니지만 (주로 TLS로 깎아 먹는 성능 때문에) 그럼에도 강한 반대를 표시한 사람이 없을 정도로 이미 IT 업계에서 암호화가 필수라는 것은 상식이 되었습니다.

  3. 구 SSL에 보안 문제가 많았다고 했는데, 이런 문제들을 암호학자들도 마침내 인식하기 시작해 최근의 TLS 프로토콜에는 최신의 빠르고 더 안전한 암호학 알고리즘들이 들어가기 시작했습니다. 물론 최신 브라우저가 필요하지만 요즘 브라우저는 자동 업데이트를 하기 때문에 의외로 이 알고리즘들을 쓸 수 있는 브라우저는 국내에도 상당히 보급되어 있습니다(당장 기사에 크롬이 과반이라고 써 두셨군요?). 이 때문에 더 이상 TLS가 느려서 못 쓰겠다는 말은 하지 못 하게 되었습니다. 애초에 트래픽에 매우 민감한 웹사이트인 구글이 TLS를 쓰고 있는 시점에서 이 성능 타령은 낡은 것이 된 게 사실입니다.

이제 기사로 돌아와 봅시다. 구글이 일단 첫 발짝을 떼었기 때문에 기사에는 구글만 언급되어 있습니다만 실상은 모든 주요 브라우저 개발사들(이를테면 모질라 파이어폭스[2])이 크롬과 같이 HTTP 연결을 낡은(obsoleted) 것으로 취급하여 장기적으로 없애 버려야 한다는 데에 동의하는 상황입니다. 과거에 인증서가 값비쌌던 시기에는 돈 때문에 HTTP를 쓴다는 것이 그나마 납득이 가는 이유기라도 했습니다(제시된 사이트의 운영자들이 인증서를 사는 비용이 한 사람 인건비 정도 밖에 안 된다는 점은 차치하더라도). 그러나 이제 정말로 귀찮아서 또는 사이트가 버려졌기 때문에(제 웹사이트 같은 경우지요...) 안/못 쓰는 경우를 제외하면 HTTPS를 쓰지 못 할 이유는 존재하지 않습니다.

대신 암호화와 복호화 과정을 거쳐야 해 응답 속도가 떨어진다. 또 인증기관의 인증서(기술)를 사서 적용하는 데 최소 수만~수십만원이 든다.

대규모 웹사이트의 경우 HTTP/2로 인한 성능 향상이 TLS로 인한 성능 하락보다 훨씬 높기 때문에 전혀 상관이 없습니다. 오늘날 TLS로 인한 성능 하락은 기껏해야 5% 아래로 알려져 있으며 [3], 다른 부분을 손보면 쉽게 수복할 수 있는 수준의 성능 하락입니다.

선술했듯 Let's Encrypt를 사용하면 최저 수준(도메인 인증이라고 하며, 해당 인증서의 소유자가 도메인을 소유하고 있다는 것만 보장해 줍니다)의 인증서를 무료로 발급받을 수 있습니다. 은행이나 전자상거래 같은 데서는 더 높은 수준의 인증서를 필요로 할 수 있으나, 여기서 말하는 "수준"은 암호화 수준이 아니며 인증서가 그 인증서의 소유자에 대해 얼마나 더 많은 걸 말해 주는지를 가리키는 것이기 때문에, 어느 수준의 인증서를 사용하든 크롬(과 앞으로의 브라우저들)은 잘 암호화되어 있으니 안전하다고 판단할 것입니다.

이에 이용자 개인정보를 요구하는 곳 등만 새 방식을 적용하고, 첫 화면 등은 기존 방식을 유지하는 누리집이 많다. 네이버는 “속도 저하 때문에 첫 화면은 기존 방식대로 두고 로그인과 검색 화면부터는 전부 새 방식이 적용돼 개인정보 보호 측면에서는 문제가 없다”고 밝혔다. [...] 네이버 관계자는 “중소기업과 스타트업들은 새 방식으로 전환하고 싶어도 비용 때문에 엄두를 못 낸다. 우리도 1억원 가까이 들었다. 구글이 이런 상황을 고려하지 않는 것은 문제”라고 지적했다.

다시 개인 의견이라는 것을 강조합니다만 이는 매우 기만적인 발언입니다. 왜냐하면 첫 화면을 (암호화되지 않은 연결로) 받은 뒤에 다음 암호화된 화면으로 가는 과정에서 공격자가 개입(man-in-the-middle attack)하면 얼마든지 공격자가 원하는 사이트로 사용자를 보내 버릴 수 있기 때문입니다. 네이버는 이미 첫 화면에서 다른 웹사이트로 가는 직접 링크를 많이 가지고 있기 때문에 사용자 입장에서는 도메인이 바뀌었다는 것으로 공격 여부를 알 수조차 없습니다(물론 대부분의 사용자는 이마저도 인식하지 못합니다만 가능하다 쳐도). 십수년에 걸쳐 IT 업계가 뼈 아프게 얻은 교훈은, 아주 아주 좋은 이유가 없지 않은 한 암호화는 사이트에 처음 접속한 그 순간부터 적용되어야만 안전하다는 점입니다. 심지어 현 세대의 브라우저는 사이트 접속 이라 TLS에서 근본적으로 벗어나 있는 상황에도 사용자가 안전하게 접속할 수 있도록 하는 대안책을 여럿 제공하는 상황이란 말입니다.

네이버는 겉으로의 발언과는 별개로 네이버 나름의 사정이 있을 수 있습니다만, 이러한 주장을 여과 없이 소개하는 것 자체가 언론으로서 큰 비판을 받을 일이라고 개인적으로는 생각합니다. 중소기업과 스타트업 핑계를 대고 있으나 얼마나 많은 스타트업이 HTTPS를 기본으로 사용하는지 확인도 해 보지 않았으며, 1억원 가까이 드는 것이 네이버의 매출에 얼마나 큰 영향을 줄 수 있는지에 대한 상식적인 고려도 없었고, 무엇보다 "안전하지 않음" 딱지를 회피하기 위해서는 이미 무료 솔루션도 존재한다는 것을 전혀 생각하지도 않고 기사를 쓴 것입니다! 언론사의 기사는 쓴 사람(들)의 수천, 수만배가 읽게 됩니다. 아무리 기사를 쓰면서 빠질 수 있는 부분이 있다 하더라도 기본적인 확인조차 되지 않은 채 기자들보다도 더 비전문가일 일반 대중에게 명백히 문제가 될만한 내용을 제시하는 것이 한겨레가 지향하는 언론의 자세라고 생각하진 않습니다.

긴 글 읽어 주셔서 감사하며 빠른 수정을 기대하고 있겠습니다.

주석

  1. http://blog.jgc.org/2015/11/the-secret-message-hidden-in-every.html
  2. https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/
  3. https://www.maxcdn.com/blog/ssl-performance-myth/ 등. 다양한 벤치마킹이 있는데 거의 일관된 결과를 보여 줍니다. 일반적으로 압축이 더 이상 되지 않는 매우 커다란 데이터를 전송해야 하는 상황 정도에서나 성능 수복이 어려운 (그러나 그마저도 성능 하락은 제한되는) 수준입니다.

반론

메일을 공개할 가능성을 염두에 두고 글을 썼으나 그렇게 정돈되진 않은 까닭에 몇 가지 중요한 지적을 받았다. 나오는 대로 아래에 추가하겠음.

  • Let's Encrypt는 제시한 것만큼 충분히 간단하지 않으며 중소기업 같은 경우는 실제로 도입에 문제가 생길 수 있다. --- 어느 정도 일리가 있는 지적이나 그럼 일단 네이버를 예제로 들었으면 안 될 것이다. 지적한 대로 LE가 아직 완벽한 솔루션은 아니며, 앞으로 웹 호스팅 등에 연동되거나 좀 더 자동화되거나 하는 건 숙제로 남아 있지만, 그것이 면죄부가 되지는 않는다. 예를 들어 작은 웹사이트라도 개인정보를 받는다면 개인정보 보호법에 따라 개인정보를 어떻게 관리할지 계획을 수립하는 것이 법적으로나 도덕적으로나 옳은데, 마찬가지로 암호화도 같은 시각에서 바라보아야 할 것이다. 이 기사는 앞으로 어떤 문제가 생길 수 있으며 사이트 운영자는 어떤 방법으로 도움을 받아야 할지, 그런 게 부족하다면 그런 점을 지적하여 유관 부서를 찌르는 식으로 쓰여졌어야 했다.

  • CPU 연산량보다 (L4 이상의) 스위치가 얼마나 받아주느냐가 문제이다. --- 이 또한 맞는 지적이긴 하나 대규모 웹사이트에서나 고려해야 하는 사안이다. 그리고 나는 솔직히 말하면 네이버가 1억 들었다는 걸 믿지 않는다. 인건비 포함해서 십수억 정도는 들었겠지. 대규모 사이트는 당연히 대규모 사이트이기 때문에 생기는 문제들이 있기 때문에 그런 것이 일반화되어서는 안 될 것이며, 중요한 건 IT 산업에서 암호화에 대한 인식이 어떻게 변화했는지와, 그런 변화를 따라 잡을 상당한 시간적 여유가 있었다는 점이다. 난 네이버가 구글보다 3년 이상 늦게 이 변화를 수용할 정도로 기술적으로 뒤쳐진다고 생각하지 않는다.

@eigen94
Copy link

eigen94 commented Feb 14, 2017

좋은 글 잘 읽었습니다. 정말 감사합니다.

@BlizzardBlue
Copy link

👍

@byungk
Copy link

byungk commented Feb 15, 2017

👍

@Noel-bk
Copy link

Noel-bk commented Feb 16, 2017

👍

@rishubil
Copy link

👍

@pjhjohn
Copy link

pjhjohn commented Feb 24, 2017

👍

@widyou
Copy link

widyou commented Mar 13, 2017

👍

@sangwoo-joh
Copy link

👍

@kalihman
Copy link

👍

@leewin12
Copy link

👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment