728x90

대세는 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 - 서버간의 통신이 이슈가 될 상황이 훨씬 적을거라는 추정이 가능합니다.



728x90
728x90

웹 서버의 응답은 브라우저나 프록시, CDN 등 모든 계층에 있어서 중요한 값입니다. 특히 컨텐츠가 캐시되어야 하는 경우 혹은 캐시되지 말아야 하는 경우에 대하여 정확한 지시자(Directive)를 내려주지 않으면 잘못된 정보가 캐시되고 다른 사용자들과 공유되어 보안사고나 정보 유출이 있을수도 있고, 엉뚱한 컨텐츠가 캐시되어 제대로된 서비스가 제공되지 못할 수도 있습니다. 따라서, 정확한 헤더와 적절한 지시자를 내려주는 것이 중요합니다.


공개되어 있는 완성된 제품 (예: 워드프레스) 을 이용하는 경우에는 솔루션이 적절한 헤더 값으로 응답을 합니다만 직접 모든 것을 개발한 웹 서버, 웹 서비스라면 필요한 값을 적절히 지정해주어야 합니다. 단순한듯 복잡한 HTTP 헤더의 세계이기에 어떤 값을 어떻게 써야하는지 헷갈릴때가 많은데요 이럴때 도움이 될만한 의사결정차트(?)가 있어서 공유해 봅니다. 


출처 : 구글 개발자 문서 (https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching)



no-cache 와 no-store 가 항상 헷갈렸었는데요 no-cache 의 경우 Etag 등이 추가적으로 제공되어야 하며 이를 통해 컨텐츠를 "항상" revalidate 하는 작업이 필요하다는 이야기가 있습니다. 다소 복잡하다면 캐시하면 안되는 컨텐츠는 no-store 를 쓰도록 하는 것이 마음이 편할 것 같습니다 ^^ 캐시할 컨텐츠는 Cache-Contro: max-age=xxx 를 사용하되 private, public 중 어떤 추가 디렉티브를 쓸 것인지도 고민해봐야 겠습니다! Etag 는 이 모든 걸 떠나서 가능하면 넣어주는게 CDN, Proxy 를 대비하는 방법이 되겠습니다!


  • # 구글 개발자 문서 : https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching


- NoPD -

728x90
728x90

최근 멀티 폼팩터 디바이스들이 사용자들에 의해 사용되면서 웹 사이트 개발, 서비스 하는 분들의 고민이 참 많습니다. 웹 사이트는 결국 사용자 브라우저 입장에서는 HTML 과 CSS 그리고 여러가지의 Resource File 로 구성된 집합체입니다. 웹 사이트를 제대로 최적화하기 위해서는 내 서비스가 가지고 있는 약점이 무엇이고 어떻게 개선할 수 있을지를 찾아내는 것이 중요하다 하겠습니다.


슬라이드 쉐어에서 발견한 자바까페(JavaCafe) 김흥래 님이 정리해서 올려주신 슬라이드 자료는 (13회 자바 개발자 컨퍼런스에서 사용된 자료인 것 같습니다) 그동안 본 자료들 중에서도 가장 쉽고 임팩트 있게 설명해주신 자료라 생각되어 공유해 봅니다. 슬라이드만 공유되어 있어서 실제 세션 발표하시면서 해주셨을 이야기가 없다는게 조금 아쉬운 부분이네요! 웹 관련 개발 업무를 하시는 분들은 필독하시고 사이사이에 간략히 설명된 내용들을 찾고 공부하실 필요가 있습니다! 


개인적인 친분은 없지만 자료 공유해주신 김흥래님께 감사인사를 드립니다 ^^


728x90
728x90
node.js 의 다양한 라우팅 모듈들 중 가장 사랑받고 있는 모듈이 express 가 아닐까 싶습니다. 사용법이 간단하지만 상당히 훌륭한 기능을 제공하고 있기 때문에 애용하는 분들이 줄어들지 않는 것 같습니다. 새로 간단한 웹 페이지를 구성할 일이 생겨서 간만에 express 를 다시 만지다 보니 버전이 올라가면서 바뀐 부분도 있고 헷갈리는 부분도 있어서 기록삼아 남겨둡니다.

$ npm install express

 
express 를 이용하기 위해서는 우선 node.js 가 설치되어 있어야 하고 npm 을 통해서 express 를 설치해야 합니다. 레파지토리를 통해 express 의 설치가 완료되면 간단한 코드를 이용하여 정적인 메세지를 출력해 봄으로써 설치가 잘 되었는지, 기본적인 사용법이 어떻게 되는지 확인해 볼 수 있습니다

var express = require('express');
var server = express();

server.get('/', function(req, res, next) {

res.send('hello express');

}); 

server.listen(1234, function() {

console.log('Server running at http://127.0.0.1:1234/');

}); 

 
보통 express 를 쓰는 예제들을 보면 app 이라는 약어를 많이 씁니다만 결국 서버니까 습관적으로 server 라고 지정했습니다. server.get 메소드를 이용하여 루트 ('/') 접근에 대해 hello express 라는 응답을 리턴하는 코드입니다. server.get 대신 server.use 를 사용해도 결과는 동일합니다.

$ node test.js
Server running at http://127.0.0.1:1234/ 


node 를 이용하여 저장한 파일을 실행하고 브라우저로 localhsot:1234 를 접근하면 정상적으로 hello express 메세지가 노출됩니다.

 
728x90

+ Recent posts