대세는 https 입니다. 새로운 http 표준인 http/2 (aka h2) 는 Clear Text 에 관한 규약을 가지고 있긴 하지만 시장에 있는 대부분의 브라우저들은 TLS 기반의 통신을 http/2 를 이용하기 위한 기본 조건으로 내걸고 있습니다. 프로토콜의 변화 뿐만 아니라 렛츠인크립트(Let's Encrypt)와 같은 무료 인증서 배포가 대중화되기 시작하면서 스트리밍(Streaming)과 같이 레이턴시(Latency)에 민감한 부문을 제외하면 전반적인 https 로의 전이가 그리 오래 걸릴 것 같지는 않습니다.


WWDC 2016 에서 애플은 ATS 에 대한 정책 강화를 통해, 앱의 인터넷 구간 통신 프로토콜로 https 를 강제하기 시작했습니다. 자세한 글을 [이곳에서] 읽으실 수 있습니다.


그런데 https 규약 자체가 보안을 의미하지는 않습니다. https 는 공개키 기반의 인증 기술을 활용하여 브라우저(클라이언트)와 서버가 통신하는데 있어서 외부에서 침투할 수 없는 채널을 만들어주는 기술이지 사전에 악의적인 사용자가 서버측에 대한 탈취를 한 경우에는 큰 소용이 없습니다. 소위 맨 인더 미들 어택(MITM, Man In The Middle Attack)과 같은 것들이 그런 사고를 지칭합니다. 때문에 공개키 기반이라는 특성을 활용하여 SSL/TLS Handshake 를 하는 과정에 일종의 검증 절차를 넣어 그런 사고를 줄이고자 하는 것이 OCSP (Online Certificate Status Protocol) 입니다.


출처 : WWDC 2016 - 애플 시큐리티 세션


OCSP 는 기본적으로 클라이언트와 서버가 통신하는데 있어서 인증서를 발행한 사업자, 소위 CA (Certificate Authority) 라고 불리우는 회사의 서버를 통해 내가 접속하고자 하는 서버가 올바른 서버인지를 확인하는 절차입니다. 이 배경에는 각 CA 가 인증서를 발급하는 과정에 취하고 있는 다양한 확인 절차가 있습니다. 이 절차를 통해 발급된 인증서는 믿을 수 있다는 전제하에 클라이언트가 서버로 부터 전달받은 인증서를 발급자에게 "유효하고 정상적인 인증서인가?"를 질의하는 절차입니다.


문제는 안그래도 SSL/TLS Handshake 로 https 통신을 시작하기 위한 비용과 시간이 큰 편인데 CA 의 서버까지 컨택하고 와야 하니 딜레이가 더 커지면서 웹 사이트나 서비스 이용에 안좋은 영향을 끼치기 시작했다는 점입니다. 여기에 더하여 CA 의 서버가 과부하 등으로 제대로 응답하지 못하거나 이슈가 생긴 경우에는 OCSP 가 제대로 진행되지 못하는 상황이 발생할 수 있다는 것이 확인되었습니다. 그래서 이런 절차를 조금더 단순화하면서도 보안을 여전히 보장해보자 하는 관점에서 등장한 것이 OCSP Stapling 입니다.


출처 : WWDC 2016 - 애플 시큐리티 세션


OCSP Stapling 은 "스테이플링" 이라는 이름에서 보이는 것처럼 인증서가 유효하다는 정보를 클라이언트가 접속하고자 하는 서버가 CA 의 인증 서버를 통해 확인받고 이 정보를 사용자에게 인증서를 전달할때 같이 주는 방식입니다. 클라이언트가 글로벌에 분포된 불특정 다수의 사용자라고 하면 서버는 상대적으로 훨씬 적은 수라는 점에서 CA - 서버간의 통신이 이슈가 될 상황이 훨씬 적을거라는 추정이 가능합니다.



저작자 표시 비영리
신고
Posted by 노피디
Development2015.09.07 12:37

크롬 브라우저가 새로운 버전(v45) 으로 업데이트 되면서 성능 개선에 대한 이야기가 많이 나오고 있습니다. 그런데 성능 개선과 별도로 일부 서비스에서는 이슈가 발생하기 시작해서 살짝 살펴보았습니다. 개인적으로 경험한 웹 사이트는 SK텔레콤의 포털인 T World 에서 로그인이 제대로 되지 않는 현상이었고 이는 현재 진행형으로 오류가 발생하고 있습니다. 아마도 서비스 개발팀 쪽에서는 인지하고 있을 것 같은데, 조치가 서버단에서 이루어져야 하는 관계로 시간이 소요되는 것으로 보입니다.


구글 Chromium 그룹에서 이야기 되는 내용에 따르면, 1) 크롬은 여전히 v45 에서 TLS v1.0 을 지원하고 있으니 TLS 버전 이슈는 아님, 2) 다만 크롬이 접속하려는 서버가 TLS Handshake 하는 과정에 이슈가 있을 경우, 기존에는 크롬이 Workaround 해주었지만, 3) v45 부터는 더이상 해당 Workaround 를 지원하지 않아서 발생하는 문제다 정도입니다. 구체적으로 어떤 웹 서버의 특정 버전이 이슈가 있는 것인지는 명확하게 정리된 내용을 찾지 못했습니다만 조치를 위해서는 서버측의 TLS Handshake 에 대한 보완이 필요한 것으로 추정됩니다.




SK텔레콤의 T world 의 경우 대표 도메인에서 로그인 시에는 별도이 도메인으로 이동하여 인증처리를 하고 있는데요, 해당 도메인이 TLS Handshake 상의 버그를 가지고 있는 것으로 보입니다. curl 로 서버의 종류를 판별해 보려고 했으나 잘 되지 않아 말씀드리긴 애매합니다. 여튼, 서비스를 운영하시는 분들중 특히 TLS 를 이용하여 HTTPS 통신을 할 때, 서버가 문제 없는지 크롬 v45 이상으로 확인해 보실 것을 권고해 드립니다.




[ ERR_SSL_FALLBACK_BEYOND_MINIMUM_VERSION 관련 참고글 ]

https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/cuHipbsCYSI




저작자 표시 비영리
신고
Posted by 노피디

티스토리 툴바