• 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)

더 웃긴 건 Firefox(이하 FF), Opera, IE, Safari, Chrome 처럼 특정 브라우져에서 잘 나오면 되는게 아니라 IE 5.5, IE 6, IE 7, IE 8 등 특정 브라우져의 특정 버젼에서 다 잘나오도록 만들어야한다는 점입니다. 10년 쯤 지나게 되면 IE 5.5, IE 6, IE 7, IE 8, IE 9, IE 10, IE 11, IE 12, IE 13, IE 14 등등 20개도 넘는 브라우져에 대한 테스트를 진행하게될 지도 모르겠습니다.

혹시 앞에서 얘기한 것에 조금 이상한 점을 발견하셨나요? 특정 브라우져의 특정 버젼에 맞춰야 한다고 얘기하면서 IE 5.5, IE 6, … 등 특정 버젼의 IE만을 언급하고 있죠? FF, Opera, Safari, Chrome 등은 마이너하게 사용되고 있기 때문에 특정 버젼에서 잘 보이는지를 체크할 필요가 없는걸까요? 아직까지 메이져 업데이트가 없었기 때문에 최신 버젼에만 맞추면 되는걸까요?

답은 ‘아닙니다.’ 입니다. FF의 전신^[1]인 Mozilla는 지난 수 년간 0.7, 1.0, …, 1.6 식으로 업데이트가 이루어져 왔고, FF의 경우도 0.9, 1.0, … , 3.0 에 이르기까지 많은 변화가 이루어져 왔습니다. Safari 는 곧 3.0을 출시할 예정이구요. 그런데 왜 FF 1.0, FF 2.0에서 잘보이는지 테스트를 할 필요가 없는걸까요?

이는 바로 이 브라우져들의 업데이트 정책 때문입니다. FF, Safari 등의 브라우져는 사용자들이 최신 버젼의 FF, Safari를 사용할 수 있도록 자동으로 업데이트할 수 있는 시스템을 갖춰두고 있습니다. 구지 구 버젼의 브라우져의 버그에 대해 마이너 픽스를 제공하기 보다는 새 버젼으로 업데이트하기를 독려하지요. 하지만 IE는 어떨까요? IE7의 경우 IE6의 비표준 렌더링 버그 등이 해결되었고, 탭 브라우징, 팝업 차단 등의 강력한 기능들이 추가되었습니다. 새로운 웹표준(CSS2.0, PNG)들도 준수하기 시작했죠. 그렇지만 사용자들로 하여금 새로운 브라우져로 업데이트를 하도록 강요하질 않습니다. IE6의 버그가 발견되면 마이너 버그 픽스를 제공할 뿐이죠.

그러다고 IE6에서 되는게 IE7에서 안되는 것은 아닙니다. 그저 소극적인 업데이트 방침 때문에 업데이트가 제대로 이루어지고 있질 않고, 그러다보니 새로 추가된 기능들(CSS2.0, PNG)들을 공격적으로 사용하질 못하게 되는 것이죠. PNG의 알파채널, CSS 2.0의 pseudo selector^[2]들을 활용할 경우 더 미려한 웹사이트를 더욱 쉽게 구축할 수 있습니다. 이를 막고 있는게 구버젼의 IE들입니다.

개발자 좀 살려주세요!란 캠페인을 보신 적이 있나요?

이 캠페인은 Internet Explorer 6 사용자가 브라우저를 업그레이드하도록 권장하는 것에 그 목적이 있습니다. Internet Explorer 6은 이미 시대에 뒤떨어졌고, 이 브라우저의 존재 때문에 많은 웹 사이트 개발자들이 보다 복잡한 환경을 고려하여 웹 사이트를 제작해야 합니다. 이로 인해 개발자들은 과중한 업무와 스트레스에 시달리고 있습니다.

새로운 브라우저들이 여러분의 웹 서핑을 보다 즐겁게 만들어 드릴 것입니다.
사람 하나 살리는 셈 치고, 브라우저를 업그레이드 해주세요!

위에 인용한 내용은 개발자 좀 살려주세요!에서 가져온 내용입니다. 저만 구 버젼의 IE가 눈에 거슬리는게 아닌가보네요. Microsoft가 업데이트 정책을 (강경하게) 바꿔서 구버젼의 IE들을 더이상 고려하지 않아도 됐으면 좋겠네요.

혹시나 IE6로 이 블로그를 보고 계신 분이 계시다면 여기를 방문해보세요. 새로운 세계를 경험하실 때가 왔습니다.

1. 혹시 아실지 모르겠지만 처음부터 Firefox란 이름을 사용한 것은 아닙니다. 원래는 Firebird라는 이름을 사용했었지만 informix 호환 opensource database인 Firebird와 이름이 겹친다는 이유로 Firefox로 이름이 변경되었습니다.
2. :first-child, :last-child 와 같은 선택자들이 CSS 2.0에서 정의하고 있는 pseudo selector 입니다. 이런 것들을 활용할 경우 디자인을 위해 내용과 관련없는 마크업을 추가할 일을 축소시킬 수 있습니다.

Related Posts

• 3/4/2009 -- ACID3 test (3)
• 4/6/2009 -- 오픈웹 관련해서 시끄러운 하루하루… (2)
• 3/14/2009 -- ‘CSS 완벽 가이드’와 역자… (1)
• 3/5/2009 -- ‘CSS 완벽 가이드’가 나옵니다. (14)
• 2/13/2009 -- div만 쓰면 웹표준? (1)

1. Transparent PNGs — The eyes are encoded as transparent PNGs.
2. The object element — The eyes of the face are attached to an object element. Being able to use object (which can have alternative content) is one of the oldest requests from web designers.
3. Absolute, relative and fixed positioning — Being able to position elements accurately is important for advanced page layouts.
4. Box model — The original Acid test focused on the CSS box model. Acid2 continues in this fine tradition by testing ‘height’, ‘width’, ‘max-width’, ‘min-width’, ‘max-height’ and ‘min-height’.
5. CSS tables — There is nothing wrong with table layouts. It is a powerful layout model which makes sense on bigger screens. However, the table markup is troublesome as it ties the content to these screens. Therefore, being able to specify table layouts in CSS is important.
6. Margins — CSS defines accurate algorithms for how margins around elements should be calculated.
7. Generated content — The ability to add decorations and annotations to Web pages without modifying the markup has long been requested by authors.
8. CSS parsing — Acid2 includes a number of illegal CSS statements that should be ignored by a compliant browser.
9. Paint order — We test that overlapping content is painted in the right order. This is not a feature in itself, but a requirement for other features to work correctly.
10. Line heights — The Acid2 test checks a few key parts of the CSS inline box model, upon which any standards-compliant Web page depends.
11. Hovering effects — One of the elements in the face changes color when you “hover” over it. Which one?

더 자세히 알고 싶으시면 Acid2: The Guided Tour 페이지를 참고하시면 되고, 한글로 소개된 자료가 필요하시면 요기를 확인해보시면 됩니다.

어쨌거나 곧 출시될 Internet Explorer 8을 포함하여 대부분의 브라우져들이 Acid2 test를 통과했는데, 이건 그저 시작에 불과하다는거죠. ;) XHTML 1.0, HTML 5.0, CSS 3.0, ECMA Script, SVG 등 웹표준은 계속해서 발전해가고 있기 때문에 이를 얼마나 발빠르게 지원하는지를 테스트해보기 위한 새로운 지표가 필요해졌고, The Web Standard Projects에서 새로운 Acid test인 Acid3 test를 제공하게 되었습니다. (여기까진 다 옛날 얘기!)

뭐 하여튼 애플의 Safari 4 Beta도 출시되었고, Firefox 3.1beta 등도 출시되는 기념으로 각종 브라우져들을 이용하여 Acid3 test를 돌려봤습니다.

위 세 이미지는 순서대로 Firefox 3.0.6, Safari 4 Beta, Chrome에서 테스트한 Acid3 결과입니다. Safari4 Beta만이 Acid3 test를 통과하였는데, 어쨌든 Chrome이 Firefox 3.0보다는 더 높은 점수를 얻었네요. Safari3는 Chrome에 사용된 것과 같은 Webkit을 사용하므로 동일한 결과를 보일 것으로 생각됩니다.

위 결과를 보시고 IE는 과연 어느 정도일까! 를 궁금해하시는 분들이 많을거라 생각합니다.

참담하네요. 순서대로 5.5, 6.0, 7.0, 8.0rc1 버젼에서 테스트한 결과입니다. 8rc1 버젼에서는 점수가 표시되는 경지에 다다랐지만 여전히 부족한 모습입니다.

참고로 Acid3 test는 WEB 2.0을 얼마나 잘 지원하는지에 대한 테스트라고 하네요. 테스트 항목은 다음과 같습니다.

1. DOM2 Core
2. DOM2 Events
3. DOM2 HTML
4. DOM2 Range
5. DOM2 Style (getComputedStyle, …)
6. DOM2 Traversal (NodeIterator, TreeWalker)
7. DOM2 Views (defaultView)
8. ECMAScript
9. HTML4 (<object>, <iframe>, …)
10. HTTP (Content-Type, 404, …)
11. Media Queries
12. Selectors (:lang, :nth-child(), combinators, dynamic changes, …)
13. XHTML 1.0
14. CSS2 (@font-face)
15. CSS2.1 (’inline-block’, ‘pre-wrap’, parsing…)
16. CSS3 Color (rgba(), hsla(), …)
17. CSS3 UI (’cursor’)
18. data: URIs
19. SVG (SVG Animation, SVG Fonts, …)

Internet Explorer 노력하세요.

Related Posts

• 3/10/2009 -- 맘에 안드는 Internet Explorer 업데이트 방침! (0)
• 3/5/2009 -- ‘CSS 완벽 가이드’가 나옵니다. (14)
• 2/13/2009 -- div만 쓰면 웹표준? (1)
• 6/11/2010 -- 2회 HTML5 열린 세미나 후기… (0)
• 8/10/2009 -- CSS로 탭 내비게이션 구현하기… (1)