• NCHOVY 인터넷 스톰 센터 – 오픈웹의 ActiveX 논쟁
• 방준영 – 인터넷 뱅킹과 ActiveX
• 서린 – 아주 조금 더 풀어 쓴 인터넷 뱅킹과 Risk Analysis
• 서린 – 분석하기 보단 분노하기 쉽다
• 버그 트럭 – 인터넷 뱅킹과 액티브 엑스 논란에 대해서
• 김휘강 – 오픈웹에서 오해하기 쉬운 사실 #1
• 이경문 – 오픈웹에서 오해하기 쉬운 사실 #2

일부 흥미로운 내용들도 있지만 감정에 치우친 글들도 많다. 방준영씨의 경우는 크게 다음 두 가지를 문제 삼고 있는데…

1. 해외에서 ActiveX 없이 안전하다고? 니네가 페이팔 피싱 사례를 모르는구나?
2. 공인 인증서는 보안 접속이 아니니까 쓸 필요가 없다고?

이 중 공인 인증서에 관련된 내용을 인용하면 다음과 같다.

그래서 아이디/패스워드만으로 보안을 담보하는 건 안전하지 않고, 돈을 보내고 받는 일은 불편하더라도 공인인증서같은 본인 확인 수단이 필요하다고 생각한다. 그런데 저 교수분의 주장은 공인인증서는 보안 접속이 아니라서 반드시 쓸 필요는 없다고 한다. 보안 접속은 영어로 secure connection이니까 당연히 공인인증서가 시큐어 커넥션일 리 없다. 공인인증서는 영어로 public key certificate니까. 그런데 이게 왜 공인인증서를 안써도 되는 이유가 되는 것인지…?

Founders at Work라는 책에 보면 페이팔 창립자가 인터뷰를 하면서 금융 사기꾼들을 막느라 고생한 이야기에 대해 상당 시간을 할애하고 있다. 특정 회사를 상대로 대규모로, 지속적으로 금융 사기를 벌이는데 못 막아서 쩔쩔 매다가 엄청난 금전 손해를 보거나 아예 어떤 회사는 문까지 닫은 이야기는 한국에서는 상상하기 힘들다. 처음부터 공인인증서 시스템을 만들어 놓고 본인 인증을 철저히 했는데도 그런 일을 당했을까?

김기창 교수님이 오픈웹에서 얘기하고 있다시피 사실 공인 인증서는 보안 접속과 관련된 부분이 아니다. 공인 인증서는 암호화된 통신을 위해 사용하는 것이 아니라 전자 서명에 사용된다. 전자 서명이 뭐냐고? 우선 오래전부터 email 에 사용되는 PGP Signature를 살펴보자.

Enigmail을 사용할 경우 메일을 보낼 때 메일의 내용을 일정 길이로 만들고(Hashing) 이렇게 만든 문자열을 자신의 비밀키를 이용하여 암호화 하여 메일 내용 뒤에 덧붙이게 된다. 메일을 받아보는 사람들은 내 공개키를 이용해서 이 서명을 풀어보고, 이 메일이 내가 보낸 것이라는 것을 확인할 수 있게 된다.

바로 이 개념이 전자 서명이다. 거래를 할 때 내 공인인증서(비밀키)를 이용하여 거래 내역을 서명^[1]하면, 은행 등에서는 내 공개키를 이용하여 거래를 한 사람이 나라는 것을 증명할 수 있다.

데이터를 https로 보내건 activeX를 이용해서 암호화 한 뒤 http로 보내건 공인 인증과는 무관하다. 오픈웹에서 하는 얘기는 공인 인증서를 사용하지 말자는 얘기까지는 아니라고 생각한다.

그리고 피싱 문제는 ActiveX로 도배한다고 방지되는 것이 아니다. 이건 정말 사용자가 주의를 기울여야 하는 문제라고 생각한다. 부끄럽지만 나도 페이팔 피싱 사이트에 당한 적이 있다. 피해를 보기 전에 부랴부랴 비밀번호를 바꾸긴 했지만, 아무 생각없이 로그인을 시도했었고, 그로 인해 내 비밀번호가 노출되었던 적이 있다. 아무 ActiveX에나 예를 클릭하고, 의심없이 로그인하는 그런 문제를 피해가려면 어느 정도 교육이 필요하다.

공인 인증서를 사용할 경우 피해를 줄일 수 있는건 분명하지만 현재 상황처럼 ActiveX 도배가 피해를 줄이는 건 아니다. 다시 한 번 말하지만 ActiveX 도배는 답이 아니다.

다음으로 이경문씨의 ‘오픈웹에서 오해하기 쉬운 사실 #2‘을 살펴보자. 이경문씨가 문제삼고 있는 부분은

1. SSL을 사용할 경우 ActiveX를 사용할 때보다 보안이 월등하다고?

뭐 요정도다. ‘SSL이 그렇게 단단해보일지 모르겠지만 SSL MITM(Man In The Middle) Attack 에 취약하기 때문에 맘만 먹으면 중간에서 데이터를 가로채고 변조할 수 있다. 심지어 서버나 클라이언트 이 둘 모두를 감염시키지 않고도 이런 일을 하는게 가능하다.’ 라는 주장.

사실 이 쪽으로는 잘 모르기 때문에 인터넷을 찾아봤다. 그 중 아래 사이트가 가장 설명을 잘해놓은 것 같다.

• SSL MITM Attack Over Wireless
• MITM Attack Over Wireless Demo

간단하게 요약해보면 다음과 같다.

1. 공격자는 Wireless AP를 가장한다.
2. 사용자가 인터넷에 접속하기 위해 AP를 찾고 공격자의 허위 AP에 접속하게 된다.
3. 사용자가 인터넷 뱅킹 사이트에 접속할 경우 변조된 DNS와 사이트를 이용하여 값을 가로챈다.

위에 써진 말 만으로 잘 이해가 안되면 ‘SSL MITM Attack Over Wireless‘에 삽입되어 있는 슬라이드 4페이지를 살펴보는 게 좋을 것 같다.

그런데 이상한게 있다. verisign 등의 상위 인증기관을 통해 인증서를 사인하지 않는다면 유효하지 않은 인증서라는 에러가 나온다. 공격자의 허위 인증서를 상위 기관에서 사인해줄 리가 없고, 이 공격을 당할 경우에는 인증서가 유효하지 않는다는 경고창이 나온다. 하지만 90%의 사용자는 이 경고를 무시해버리는 특성이 있고, 그렇기 때문에 문제가 있다고 주장한다.

그런데, 이게 SSL만의 문제냐면 그렇지 않다. ActiveX기반의 암호화 통신에도 똑같은 공격 방식이 적용될 수 있기 때문이다. 누가 더 안전하고 말고의 문제가 아니란 얘기.

‘김휘강 – 오픈웹에서 오해하기 쉬운 사실 #1‘의 경우는 기술적이기 보다는 정치적인 이유로 개선되기 힘든 상황을 설명하고 있다. 그런데 간과하고 있는게 있다.

사실 오픈웹은 ‘무조건 걷어내야 한다.’라고만 주장하고 있지는 않다. 다만 다른 곳에서도 사용이 가능하도록 Fall back 을 제공해달라는 것이다. 물론 요새 김기창 교수님이 조금 강경/빡빡하게(혹은 삐딱하게) 주장을 펼치시다 보니 위에 링크를 건 어떤 분의 글처럼 ‘분석을 하기보단 분노 하고 있는 것‘ 일지도 모르겠다.

내가 생각하기에 Microsoft Windows + Internet Explorer 를 사용하는 고객에게는 지금 상황을 그대로 제공하는 건 뭐 맘대로 하라고 두고 싶다. 하지만 이 외의 OS, 이 외의 브라우져에서도 사용할 수 있도록 Fall Back을 제공해달라는 것이다.

Microsoft Windows의 경우 지난 몇 해간 수 없이 많은 보안 취약점이 노출되었고, 이를 공격하기 위한 웜/백도어 등이 수없이 만들어졌다. 물론 Microsoft Windows 사용자 중에는 IT에 지식이 없는 평범한 사용자가 많다보니 더 위험에 많이 노출되었을 수 있을 것 같다. 그런데 이런 상황을 고려하지 않고, 위험에 심하게 노출되어 있는 사용자 환경과 상대적으로 위험에 적게 노출되어 있는 사용자 환경(리눅스/맥)을 동일한 잣대로 평가하고, 동일한 기능을 제공해야한다고 주장하는 것은 옳지 않다.

조금 오래된 글이지만 KLDP에 올라왔던 ‘리눅스, 키보드 보안‘ 글을 살펴보자. 조금 기술적이다보니 관련 지식이 없다면 내용을 이해하기 쉽지 않을 수도 있을 것 같다. 결론을 요약하자면 ‘윈도우 기준으로 키보드 보안 모듈을 요구하는데, 리눅스에는 오히려 이런 보안 모듈을 허용하는 것 자체가 취약점을 노출시키는 것이다.‘ 정도로 얘기할 수 있을 것 같다.

2006년 오픈웹에 올라온 글에서 발췌한 내용을 살펴보자.

ActiveX 플러그인이건, NPAPI 플러그인 이건, 그 플러그인을 호출, 구동하는데 필요한 파라미터 명칭이나, 필드값은 동일하게 설계하면 됩니다. 즉, 서버와 플러그인 간의 인터페이스를 표준화하면 어떤 플러그인이건 간에 서버가 이를 호출하여 사용할 수 있게 됩니다.

내 생각에는 이게 바로 우리가 표준화해야할 ‘공인인증 API‘라고 생각한다.

1. 공인인증을 위한 Mimetype을 표준화한다.
2. 이 Mimetype이 object, embed 등의 태그로 삽입되었다면 공인인증 플러그인이 로딩된다.
3. 공인인증 플러그인이 파이어폭스용 플러그인일지 사파리용 플러그인일지 아님 ActiveX 일지는 중요하지 않다. 공인인증을 위한 API가 표준화되어 있으므로 동일한 코드를 통해 공인인증이 가능해지며, 서로 다른 사이트를 사용하더라도 하나의 공인인증 플러그인이 있으면 된다.

심플하고 우아한 솔루션이 아닌가?

김휘강씨의 글에서처럼 다른 플러그인을 위한 호환 코드를 넣기 보다는 이렇게 인터페이스를 표준화하는 것이 더 나은 방법이라 생각한다.

같은 얘기를 몇 년째 되풀이하고 있다. 심하게 아픈 곳이 있으면 곪아 터지기 전에 수술을 해야한다. 심하게 곪을수록 치료하려면 더 많은 고통이 필요해진다. 우리가 그렇게 많은 것을 요구하는 것은 아니라고 생각한다. 다만 너무나도 당연한 것을 너무나도 당연하게 해결하는 것. 이게 우리가 바라는 것이 아닐까?

1. 해쉬를 암호화하여 원문에 덧붙임

Related Posts

• 1/28/2009 -- 인터넷 뱅킹과 크로스 브라우징 (2)
• 10/25/2007 -- 오픈웹과 관련해서… (4)
• 2/7/2010 -- 인터넷 결제 시스템을 언제까지 익스플로러에 가둬놓을 셈인가? (3)
• 2/6/2010 -- 보안에 신경을 쓴다면 사용할 수 없는 인터넷 뱅킹… (0)
• 4/12/2009 -- 오픈웹 관련: SSL과 관련된 공격들… (2)

ps. 최근 몇몇 글에서 조금은 전문적인 시각에서 현 체제에도 장점이 전혀 없는 것은 아니다.. 라고 주장했더니 부끄러움을 호소하는 글도 심히 반박당하는군요 -_-

ps2. 금융권 쪽에서 SSL을 통해 암호화 하는 방향으로 변화하기 위해서는 일단 SSL가속기를 사야하는 추가적인 부담 and/or 화려한 홈페이지를 전반적으로 수수하게 변경해야 하는 문제가 있습니다. 쇼핑몰의 경우 전체 사이트에서 ‘로그인’과 ‘결제정보 입력’ 등의 아주 일부분만 보안연결이 필요한 반면 금융권 사이트의 경우 거의 모든 부분이 보안연결이 필요합니다.

ps3. SSL이 요구하는 연산비용은 만만한게 아닙니다.

사실 SSL의 부하가 큰 것은 사실이나 ActiveX를 사용하건 https를 사용하건 암호화를 해야한다면 똑같은 부하가 걸릴 수 밖에 없습니다. 이에 대한 내용을 코멘트로 달았고, 아래와 같은 답변을 들을 수 있었습니다.

플러그인 기반 페이지 암호화를 사용하면 페이지 중 특정 영역만 암호화가 가능합니다. 같은 html 문서 안에서도 일부분은 암호화 해서 전송하고 나머지는 평문으로 보낼 수 있습니다.

반면 SSL을 사용할 경우 html 문서나 이미지 등 http request/response 단위로 암호화가 되어야 할 뿐만 아니라 한 페이지를 이루는 모든 요소(html 문서, 이미지 등 임베딩 된 요소 등)가 SSL를 통해 암호화 되지 않으면 대부분의 브라우저에서 경고를 표시하게 됩니다. (디폴트 설정에서 크롬에서는 자물쇠 아이콘이 느낌표로 변하는 정도로 처리하지만 다른 메이저 브라우져에서는 경고 팝업이 뜹니다)

현실적으로 이용자들에게 http와 https가 혼합되어 있다는 경고 문구를 보여줄 생각이 아니라면 이미지, 플래시 등을 포함한 페이지 전체를 SSL로 암호화 해야 하는데, 이건 민감한 부분(계좌 번호, 잔액, 주민번호 등등)만 암호화 하는 플러그인 기반에 비해서 확실히 많은 부하를 주게 됩니다.

뭐 듣고 보니 그럴 수도 있겠다는 생각이 들기는 합니다. 하지만 페이게이트 사의 결제 모듈과 관련된 작업을 하면서 보니 대안이 없는게 아니었습니다.

페이게이트 사의 결제 모듈은 PGIOForm이란 이름을 가지는 form과 javascript만으로 모든 결제가 이루어집니다. 처음에는 AJAX를 사용하는 걸꺼라 생각했지만 AJAX는 Cross site 간의 통신이 불가능하기 때문에 AJAX만으로는 이런 식으로 구현할 수가 없을 것 같았습니다. 그렇다면 어떤 방법을 사용했는지가 궁금해져서 직접 소스를 분석해보았습니다.

	var langliburl = "https://api.paygate.net/util/getsource.php?srcno=" + srcno + "&mid=" + getPGIOElement('mid') + "&tid=" + getPGIOElement('tid');
 
	langlib = document.createElement("script"); 
	langlib.setAttribute("language", "JavaScript"); 
	langlib.setAttribute("type", "text/javascript"); 
	langlib.setAttribute("charset", request_charset);
	langlib.setAttribute("src", langliburl); 
	langlib.setAttribute("id", "PGIOScript" + scriptid++); 
	document.getElementsByTagName('head').item(0).appendChild(langlib);

위 코드가 바로 cross site로 값을 넘겨주고 또 값을 넘겨받기 위한 코드인데요. 보면 동적으로 script 태그를 만들어서 스크립트를 삽입하는 것을 통해 타 사이트로 값을 전달하고 있습니다. 그리고 받아온 스크립트의 내용을 참고하게 되면 타 사이트로부터 값을 넘겨받을 수도 있죠. 이 기법을 ‘JSONP‘ 라고 한다고 하네요.

구지 민감한 데이타들에 대해서만 암호화를 하고 싶다면 JSONP를 활용하면 된다는 거죠. ActiveX를 사용하게 될 경우 암호화된 데이터를 받아서 javascript를 통해 복호화한 뒤 javascript를 이용하여 보여주게 됩니다. 어짜피 javascript를 이용해야 한다면 ActiveX를 사용하나 JSONP를 사용하나 구현의 복잡한 정도는 거기서 거기일 거라 생각되네요.

별로 중요하지 않은 이미지/플래쉬 등은 http를 통해 전송되고, 민감한 데이타들은 JSONP를 통해 https 프로토콜로 전해진다. 아주 간단하죠. Viz님이 말씀하신 ActiveX로 구현을 했을 때의 장점을 모두 가지고 있으면서 보안 프로그램의 라이센스까지 필요없어지겠습니다.

참고로 JSONP를 사용하게 되면 값을 GET 방식으로 보낸다고는 하지만 https의 인증서 교환은 URI를 요청하기 전에 이미 이루어지게 되므로 누가 중간에 패킷을 가로챈다고 하더라도 어떤 URI를 요청했는지는 알 수 있는 방법이 없습니다.

Related Posts

• 10/25/2007 -- 오픈웹과 관련해서… (4)
• 3/25/2009 -- ajax와 encoding 문제… (2)
• 6/18/2010 -- HTML5 웹을 넘어 플랫폼으로… (2)
• 6/11/2010 -- 2회 HTML5 열린 세미나 후기… (0)
• 8/24/2009 -- 마우스 드래그, 마우스 오른쪽 버튼을 막아둔 것 풀어버리기 (1)

현재 문제점은 보안 채널을 제공하는데 INISafeWeb/XecureWeb 등의 activeX[1] 를 사용한다는 것과 공인인증서(비밀키)를 이용한 서명을 activeX 로만 구현해 놓았다는 것이 아닐까 싶다.

https 를 통해 128bit secure channel 을 구성할 경우 지저분한 프로그램이 깔릴 필요가 없고, 현재 사용 중인 대부분의 브라우져에서 웹페이지를 안전하게 접근하는 것이 가능해진다. 또한 보안채널을 이용할 때와 이용하지 않을 때 모두 동일한 방법을 통해 웹페이지를 코딩하는 것이 가능하기 때문에 웹 개발자/코더 입장에서도 훨씬 편하게 작업할 수 있을 것이다. 게다가 비싼 플러그인도 라이센스할 필요가 없으므로 원가 절감 효과까지 누릴 수 있다.

공인인증서를 이용한 서명의 경우의 경우는 여전히 activeX/plugin 인터페이스가 필요하겠지만 ‘공인인증서를 사용한 전자서명 인터페이스(api)’ 를 표준화 하게 되면, 공인인증서를 사용하는 사이트들을 이용하게 되더라도 각각에 대해 다른 플러그인을 설치할 필요가 없기 때문에 사용자 입장에서 더욱 편리하게 이용할 수 있을 것이다. 또한 플러그인이 할 일은 대폭 줄어들어 비밀키를 읽어 전자서명 하는 용도 정도로만 사용될 뿐이므로 구현 또한 쉬워질 것이라고 생각된다.

SEED 등 전자 서명에 필요한 모든 알고리즘은 openSSL 에 이미 구현되어 있고, 이를 이용하면 UI 정도의 작업만이 필요하게 된다. API 가 표준화 되고, 구현체가 opensource 로도 나오게 되면 멀티 플랫폼을 지원하는 건 시간 문제일 뿐이다.

개발자의 생산성을 비약적으로 향상시킬 방안이 있어도, 그 기술을 쓰는 개발자의 단가가 비싸다는 이유로 기각되곤 한다. 이는 혁신의 상실일뿐더러 기회의 상실이다. ‘보이지 않는 손’의 위업이라 해버리면 그만이지만, 정책이란 이러한 상실을 지키기 위한 것 아니었던가.

from: zdnet – 대한민국 개발자의 우울, 자기 책임론에서 구조 개혁론으로

http://www.zdnet.co.kr/it...,39030292,39161841,00.htm

공인인증서를 이용하기 위한 API 표준화, 그리고 보안 채널을 제공하기 위한 방법으로 https 를 이용하도록 마이그레이션 하는 것 이 두 가지 모두 생산성을 비약적으로 향상시킬 수 있는 방법이고, 더불어 최소한의 비용으로 드라마틱한 접근성 향상을 가져올 수 있는 방법이 될 것이다.

언제까지 이런 ‘혁신의 상실’ 을 반복하고만 있을 것인지 이를 보고 있는 난 너무나 답답하다.

[1] activeX 는 Microsoft Internet Explorer 를 확장시키기 위한 기술로 특정 프로그램을 설치한 뒤 jscript 를 통해 그 프로그램을 조작할 수 있는 방법을 제공하게 된다. 단 Microsoft Windows 에서만 사용이 가능하다.

Related Posts

• 1/28/2009 -- 번역: 한국의 홈브류 인터넷 (0)
• 1/28/2009 -- 인터넷 뱅킹과 크로스 브라우징 (2)
• 9/15/2007 -- 64bit Windows Vista 와 신한은행… (13)
• 2/7/2010 -- 인터넷 결제 시스템을 언제까지 익스플로러에 가둬놓을 셈인가? (3)
• 4/6/2009 -- 오픈웹 관련해서 시끄러운 하루하루… (2)