HTTP 2.02016.07.04 16:02

웹 컨텐츠 전송을 위한 프로토콜의 대세가 h2 혹은 http/2 로 자리잡아 가면서 맥(Mac)의 쉘에서도 http/2를 테스트 해야하시는 분들이 많이 늘었을 것으로 생각됩니다. 알려진 내용에 따르면 curl 의 7.34.1 버전 이후에는 --http2 옵션을 통해 http2 로 서버와 통신을 하도록 강제할 수 있지만 환경에 따라서 안되는 경우가 많습니다. curl 은 http/2 를 지원하기 위해 nghttp2 라이브러리를 이용하고 있기 때문에 우선은 nghttp2 를 설치해야 합니다.




nghttp2 가 설치되면 이를 이용해서 curl 을 다시 build 하거나 설치해야 합니다. 홈브루(Homebrew)를 이용하면 간단하게 새로운 버전으로 빌드를 하면서 설치할 수 있으니 아래의 커맨드를 참고해서 설치를 진행하도록 합시다. 아래와 같이 설치한 후 brew info curl 명령을 통해 nghttp2 에 초록색 체크박스가 잘 들어왔다면 일단 설치는 제대로 잘 된거라 봐도 되겠습니다.





그런데 여기까지 하고나서도 curl 을 --http2 옵션으로 실행했을 때 지원하지 않는 프로토콜이라고 에러가 떨어진다면 심볼릭 링크를 한번 교체해줄 필요가 있습니다. 환경 설정에 따라, 사용자 계정에 따라 sudo 를 통해서 권한 상승을 해야 할 필요도 있으니 상황에 따라 적절한 옵션으로 심볼릭 링크를 교체해 주시면 되겠습니다. 




여기까지 해서 마무리가 잘 되었다면 curl --http2 옵션으로 http2 가 활성화된 사이트들, 예를 들어서 아카마이의 https://http2.akamai.com 이라던가 구글 메인 페이지 (https://www.google.com) 쪽으로 요청을 던져볼 수 있게 되셨을 겁니다. 일단 개인적으로 여기까지 해서 문제는 없었습니다만 다른 문제를 겪는 분이 계시다면 댓글로 남겨주시면 한번 살펴보도록 하겠습니다!



- NoPD -




저작자 표시 비영리
신고
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 노피디
Cloud & Dev. Story2014.04.16 15:24
요즘 웹 업계가 난리입니다. 사실상 표준처럼 사용되고 있는 오픈소스 라이브러리인 OpenSSL 에서 취약점이 발견되면서 SSL 터널링과 관계 없이 사용자의 민감한 정보가 노출될 수 있는 문제가 확인되었기 때문입니다. OpenSSL 라이브러리에 대한 패치와 기존에 발급된 인증서 갱신도 중요하지만 Heartbleed 가 왜 이리 큰 이슈가 되는지 아는 것도 중요해 보입니다.

워낙 관련된 문서들이 많이 나왔고 테크 블로그나 IT 전문 매체에서도 잘 다루어 준 덕분에 이해하기 어렵지 않지만 누군가에게 이걸 다시 설명하라고 하면 구차하고 잡다한 이야기를 늘어놓게 되지요. 간단하게 정리된 웹 사이트가 있어서 소개해 드리면서 해당 사이트가 그림으로 이해하기 쉽게 그려둔 그림을 공유해 봅니다. 이해가 아주 깔끔하게 되네요!

출처 : Forumsys (http://www.forumsys.com/api-security/how-to-fix-openssl-heartbleed-security-flaw/)

 
평상시 사용자들이 브라우저로 TLS/SSL (쉽게 말해 HTTPS 요청이라고 생각하시면 됩니다) 터널링을 맺고 나면 OpenSSL 라이브러리는 생성된 세션이 유효함을 확인하기 위해 5바이트의 HELLO 메세지를 전송하는 Heartbeat (심장박동?) 를 전달하게 됩니다. 클라이언트 (보통 브라우저겠죠) 와 서버는 지속적으로 이 행위(?)를 반복하며 채널을 유지합니다.

출처 : Forumsys (http://www.forumsys.com/api-security/how-to-fix-openssl-heartbleed-security-flaw/)


그런데 이번에 발견된 OpenSSL 의 문제점은 Heartbeat 를 5바이트 이상으로 전송하더라도 이에 대해서 서버가 같은 바이트 크기만큼 메모리의 정보를 읽어서 응답하는 데에 있습니다. 악의적인 사용자가 서버의 메모리에 저장된 특정한 주소의 정보들을 쉽게 추출해낼 수 있는 방법이 생긴 것이지요. 이의 해결을 위해서는 OpenSSL 라이브러리를 갱신하고 발급된 인증서를 재발급 받는 등의 절차가 필요합니다. 보다 자세한 내용은 원문을 참고하시기 바랍니다!





저작자 표시
신고
Posted by 노피디
Development/node.js2013.07.16 09:06
Node.js 가 등장한 이후 간단히 테스트 목적의 웹 서버를 만드는 일이 손쉬워졌습니다. 단순한 Static 컨텐츠의 노출이 아닌 이상 닷넷을 이용하던 자바를 이용하던 뭔가 무거운 개발도구를 실행하고 코드 몇 줄을 넣은 후 컴파일 해야 했다면 Node.js 는 그런 번거로움과 불필요함을 한방에 날려주고 있습니다.

새롭게 옮긴 직장에서 고객사의 PUT Request 에 대한 처리를 해야 할 일이 생겼는데 고객사의 API 에 대고 신나게 테스트를 할 수 있는 것도 아니고 해서 간단하게 가상머신에 Node.js 와 Express 모듈을 이용하여 RESTful API (..라고 적었지만 그냥 PUT Request 를 처리하는...) 를 만들어 봤습니다. 혹시나 RESTful API 의 CRUD 액션을 간단히 구현할 필요가 있으신 분들 참고하시라고 올려둡니다. Node.js 와 Express 모듈을 설치하신 뒤 소스코드를 참고해서 보시면 됩니다. REST 호출 이외에도 처리를 위해 Jade 모듈도 설치후 설정이 들어가 있는데요, 이 부분은 필요하신 경우 선택적으로 쓰시면 되겠습니다.

(참고로 현재 시점에서의 Node.js 와 Express 최신 버전을 따르고 있기 때문에 보시는 시점에 따라 해당 엔진과 모듈의 행동양태가 변경되면 동작하지 않을 수도 있습니다 ^^;;)

// express_server.js
var express = require('express');
var app = express();

app.configure(function() {
	app.set('views', __dirname + '/views');
	app.set('view options', { layout: false });
	app.use(express.methodOverride());
	app.use(express.bodyParser());
	app.use(app.router);
	app.use(express.static(__dirname + '/public'));
	console.log('configure successful...');
	console.log('view directory is ' + __dirname + '/views');
	console.log('static directory is ' + __dirname + '/public');
});

app.get('/hello', function(req, res) {
	res.render('index.jade', {
			message:'hello world'
	});
});

// TYPE 1 (RESTful) : call "/puttest/3"
app.put('/puttest/:id', function(req, res) {
	res.send('received id :' + req.params.id);
});

// TYPE 2 (Traditional) : call "/puttest" with body parameter "id=9" then
app.put('/puttest', function(req, res) {
	res.send('received id :' + req.body.id);
});

app.configure('production', function() {
	app.use(express.logger());
	app.use(express.errorHandler());
});

app.configure('development', function() {
	app.use(express.errorHandler({ dumpExceptions: true, showStack: true }));
});

app.listen(81);

위의 소스코드에서 사용한 Jade 템플릿은 아래와 같이 간단하게 되어 있습니다. 그냥 그렇구나 하시면 될 것 같습니다.
// Jade 렌더링 테스트용 : /views/index.jade
#{message}

[ Node.js 의 기초를 위한 추천 도서 ]
인기 저자 윤인성 작가의  "모던 웹을 위한 Node.js 프로그래밍" [자세히보기]


- NoPD -
저작자 표시
신고
Posted by 노피디
Cloud & Dev. Story2009.08.17 08:07
미국 시간으로 8월 14일, 우리 시간으로 광복절에 윈도우 서버 2008 R2 의 평가판 다운로드가 열렸습니다. 180 일동안 사용할 수 있는 버전인데요, TechNet 과 MSDN 구독자들에게만 링크가 열린 것으로 보입니다. 일반 사용자 여러분들은 조금 더 기다리시거나 지인의 도움(?)을 받으셔야 하지 않을까 싶습니다. (평가판이니 큰 문제가 되지 않을 것 같습니다)

이미 널리 알려진 것처럼, 윈도우 서버는 더이상 32비트 하드웨어를 지원하지 않습니다. 이번에 공개된 버전도 x86 버전은 존재하지 않으며 x64, ia64 의 두가지 버전으로만 공개가 되었습니다. 개인용 PC 는 아직까지 32 비트를 포기할 수 없지만 서버 OS 는 대세가 64비트로 굳어져 가는 느낌입니다.


- NoPD -
신고
Posted by 노피디
Cloud Tech./Presentation2009.04.20 08:00
윈도우 서버 2008 에서 소개된 RemoteApp 은 Citrix 의 Presentation Server와 같은 별도의 3rd Party 솔루션 없이 기본적인 시스템 구성과 터미널 서비스 라이센스 만으로 Presentation 가상화를 가능하게 해주고 있습니다. Citrix 와 같은 전문 솔루션이 제공해 주는 강력하고 다양한 기능은 아니지만, 맛배기로는 훌륭한 수준이 아닐까 싶습니다.

로컬, 리모트의 구분이 없는 Seamless 서비스

가상화의 중요한 포인트 중 하나는, 사용자가 작업중인 환경이 로컬인지 리모트인지 알 수 없게 하는 것입니다. 가상화 환경에서 제공하는 리소스를 사용하고 있다 하더라도 마치 로컬의 소프트웨어, 서비스를 이용하는 것과 같은 사용자 경험(User Experience)가 제공될 때, 가상화는 궁극의 목표에 도달하는 것이니까요.

윈도우 서버 2008이 도입되면서 소개된 RemoteApp 은 기존에 전문 솔루션을 사용할 때 가능했던 Seamless Window 기능을 제공하고 있습니다. 사용자는 터미널 서비스 클라이언트등으로 리모트의 어플리케이션에 접근하는 것이 아니라 바탕화면의 바로가기나 시작 메뉴에 등록된 프로그램 아이콘을 통해서 어플리케이션을 실행할 수 있습니다.

원격에서 실행되는 소프트웨어는 전체 화면이 아닌 실행 화면의 창만 별도로 클라이언트로 전송되어 클라이언트의 테마에 맞추어 표현됩니다. 윈도우 서버 2008 에 데스크탑 테마 기능을 활성화 해두면 클라이언트 OS 가 Vista 이상인 경우 에어로(Aero) 까지 무리없이 표현됩니다. 진정한 Seamelss 서비스를 이제 OS 가 기본적으로 제공하는 시대가 온 것입니다.

쉬운 지점 IT 자원 관리

이전 포스팅에서 이야기했던 중앙 집중화된 관리와 비슷한 의미입니다. 본사는 전문 IT 지원 인력들이 일일이 PC 에 설치된 소프트웨어를 업데이트하고 손봐줄 수 있지만, 그런 인력이 없는 멀리 떨어진 지점은 본사에서 출장을 나가거나 별도의 외부 업체를 통해서 PC 에 설치된 소프트웨어의 장애를 해결하고 부적절하게 설치된 프로그램을 걸러내는 등의 이슈가 있었습니다.

RemoteApp 을 통해 어플리케이션을 중앙에서 배포하게 되면, 모든 문제는 서버단에서 (Server Side) 해결이 가능하기 때문에 상대적으로 적은 비용과 노력을 통해서 본사 뿐만 아니라 지점의 IT 자원 관리가 가능해 집니다. 관리의 IT 가 가능해질 수 있는 것입니다.

(계속)

2009/04/13 - [Virtualization/Presentation] - Presentation 가상화를 해야하는 이유는 무엇일까? #1

- NoPD -
신고
Posted by 노피디
Development2008.12.22 07:55

티스토리 툴바