"ActiveX에 대한 취약점"에 대한 정리
Gilbert Lee
dasony
더욱 감사드립니다.
오픈웹에서 논의되었던 각종 ActiveX로 인해 발생할 수 있는 공격 방법이 모두 정리되어있네요. 제가 굳이 언급하지 않은
Universal Wrapper 방식 등도 다 나와있어서 반갑습니다. 유명 ActiveX 컨트럴의 보안 문제를 공격하는
attack이 상당히 많이 나와있군요. ActiveX 개발 시에 가장 기본적으로 고려해야하는 부분인데, 아쉬운 일입니다. 사실
몇 년 전에 ActiveX 프로그램도 제작하는 회사에서 일했던 적이 있는데, ActiveX를 설치해야 한다는 단점을 피해가기 위
해 당시 유명하던 모 ActiveX을 이용해서 설치해버리자는 의견을 낸 적도 있었습니다. 물론 반쯤 농담이었고, 실행하지는 않았
습니다 ^^;
그런데 사실 보여주신 문서에서 생소한 이야기는 없는 것 같습니다. 오픈웹과 보안 쪽에서 이야기하는 ActiveX에 대한 입장이
어떻게 다른건가요? 오픈웹에서는 악성코드를 ActiveX로 직접 배포하는 위험을 주로 말하고 있고, 보안에서는 IE나 기존에 설
치된 ActiveX의 취약점을 통해 악성코드를 배포하는 위험을 주로 말하고 있기 때문인가요? 솔직히 말씀드려서 오픈웹에서
ActiveX에 대해 어떤 오해를 가지고 있다는 것인지 잘 모르겠습니다.
그래도 반가운 부분은 되는 부분은, 당연하지만 제가 생각만 해봤던 공격 방식 대부분을 이미 인지하고 있다는 사실입니다. 그렇다
면 어떻게든 막아두고 있겠지요. (개인적으로 Universal Wrapper는 어떤식으로 막고 있을지 궁금합니다. 몇가지 조악
한 방법은 떠오릅니다만...) 그렇게 공격 하나하나 막아가면서 운영을 하려니 타 플랫폼 지원은 꿈도 못 꾸고, 로우레벨 접근이
가능한 ActiveX를 사용하지 않고서는 못 배기는 것 같습니다. 하지만 좀 더 근본적인 대안 없이 언제까지 이렇게 갈 수 있을
지 모르겠습니다. 인내심이 부족해서 보안을 계속 팔 수 없는 저같은 사람은, 생각을 바꾸면 더 간단한 방법을 찾을 수 있지 않을
까 궁금할 수 밖에 없네요. =)
swlee
현재 게임, 음악, 정부기관, 뱅킹. 쇼핑, 증권, 교육등 거의 모든 분야에서 ActiveX는 반드시 필수로, 강제로 사용되고
있으며
ActiveX 설치 없이는 윈도우 보안 업데이트 조차 되지 안는 현재 상황에서 공공성이라는 오픈웹만의 잣대로
보안 ActiveX 모듈만을 문제삼는것이 이해가 안될 뿐입니다.
두번째로 현재 적용되어 있는 보안 접속 모델인 E2E(end- to- end )는 기술적인 측면만 보면
SSL의 암호화 접속의 단점을 보완하는 Application 레벨의 암호화를 지원하는 기술로서
모바일등의 플래폼서 SSL의 단점을 보완하기위해 채택되는 표준 보안 기술임에도 불구하고
ActiveX를 이용하여 구현했다는 이유 만으로 황당한 무용론을 주장하며 SSL로 회귀해야 한다는 주장입니다.
(기술적인 측면에서 분명히 SSL보안 접속보다 진보된 기술임에도 불구하고요..)
문제가 있으면 문제점을 보완하는것이 당연함에도 불구하고
ActiveX 로 구현했다는 이유만으로 SSL과 차이점이 없으며 걷어내야 한다는 주장은
보안업계 입장에서는 황당하죠 ..
차라리 ActiveX 가 아닌 다른 방법으로 구현이 가능하다등의 주장이면 그건 납득이 가고 이해가 가는데..
기술적으로 동작 방법에 별반 차이가 없고 오히려 SSL보다 더 취약하다는 이유로
ActiveX 를 걷어내야 한다는 주장이 어이가 없는 것이죠..
현재 ActiveX 의 문제는 MS 종속적인 기술이기 때문에 MS의 정책이 변경될때마다 한국 IT가 흔들릴 수 있으며
ActiveX 중심으로 구현된 사이트는 타 브라우저를 지원하지 못해 점점더 MS 종속화 되어 가고 있는것이 문제라 할 수 있는
데
이에대한 책임을 보안업체로 돌리는 것이 안타깝네요..
대표적인 예가 "보안 ActiveX 때문에 사용자들에게 ActiveX 가 뜰때 무조건 예를 누르는 것을 학습 시킨다."
인터넷 뱅킹이야 말로 그 무엇보다도 가장 최선의 보안대책이 구현되어야 하는 보안이 가장 중요한 사회적 행위임이 분명한데..
그러한 보안의 중요성 보다는 당장 웹 표준화, ActiveX 제거만을 외치는 부분이 안타깝습니다.
소송같은 방법을 통해 당장 무언가를 하려는 급한 모습보다는
모든 브라우저에서 잘 동작하는 사이트 TOP 100, ActiveX 를 사용하지 않고 표준화 기술을 성공적으로 적용한 CASE
소개
개발자들이 쉽게 웹 표준 기술을 적용할 수 있도록 할 수 있는 기술적 안내, 지침등
쉽게 할 수 있는 부분부터 차근차근 캠페인해 나갔으면 하는 바램입니다.
Mountie Lee
dasony
mountie님께서 직접 글을 써주셨으니 기술적인 부분을 제외하고 다시 씁니다. 일단 ActiveX라서 문제는 아니고요, 타플랫
폼에서 사용할 수 없어서 문제입니다. 오픈웹은 가장 적은 비용으로 많은 플랫폼을 지원할 수 있는 방법을 찾고 있는 것입니다.
즉 말씀하신 "ActiveX 가 아닌 다른 방법으로 구현이 가능"한 방법을 찾고 있는 것이 현재 토론의 주 내용입니다. 각 운영
체제 및 브라우져 별로 플러그인을 개발하는 제2안을 주장하기 앞서, 웹표준을 최대한 사용하는 제1안이 현재 방식보다 보안이 취약
한지에 대한 내용이지요.
책임 문제는 동의합니다. 책임 추궁보다는 대안을 찾고 있는 것이니까요. 그런데 ActiveX 전체의 문제를 보안 업계에 책임을
돌리려고 한다거나, 사용자가 yes 누르는 것까지 보안 업계만의 책임이라고 주장하는 상식적인 사람은 없으리라고 생각합니다. 실제
로 오픈웹은 가장 먼저 정부와 은행을 겨누지 않았습니까^^; 한국 웹환경에서 ActiveX 만연 현상은 우리 모두의 책임이라고
봅니다. (실제로 저 역시 ActiveX 컨트럴을 개발하던 회사에 몸담은 적이 있습니다.) 그런데 책임 추궁의 대표적인 예로 드
신 부분은, 책임 추궁보다 문제 제기로 보시면 안될까요? ^^; 혹시 제가 쓴 글을 누군가에 대한 책임 추궁으로 받아들이신 분
이 계시다면 죄송합니다.
마지막으로 말씀하신 웹표준 기술에 대한 홍보는, 오픈웹 활동과는 별개로 수년동안 끊임없이 이루어지고 있습니다. 가이드도 많이 있
고요. 그리고 실제로 몇년간 정말 엄청난 개선이 이루어져 있습니다. 웹과 관련된 일을 하시는 대부분의 분들이 표준 사용과 크로스
브라우저에 신경을 쓰고 있습니다. 개인뿐만 아니라 대형 사이트들(특히 네이버와 다음)도 크로스브라우저를 중요시 하고 있습니다.
웹 개발자 중에 현실에 치여 웹 표준 기술을 적용하지 못하고 있는 분들은 아직 있어도, 할 줄 모르는 분들은 없을겁니다. 심지
어 정부기관도 이제는 웹표준 문제에 동의하고 해결책을 모색하고 있습니다. 실제로 제가 굳이 IE를 실행하는 경우는 인터넷 뱅킹
과 쇼핑몰 및 관련 사이트를 사용할 때를 제외하고는 없습니다.
youknowit
> > ActiveX를 이용하여 구현했다는 이유 만으로 황당한 무용론을 주장하며 SSL로 회귀해야 한다는 주장입니다.
> > (기술적인 측면에서 분명히 SSL보안 접속보다 진보된 기술임에도 불구하고요..)
선뜻 납득이 가지는 않는 부분이네요... 모두가 아시는 내용이지만, ActiveX 는 프로그래밍 플랫폼의 일종일 뿐, 그 자체
가 무슨 프로그램인 것은 아닙니다. 액티브X는 프로그램을 담는 일종의 틀(framework)에 해당하는데, 막상 그 틀에 담기
는 프로그램 자체는 보안과 관련이 있을 수도 있고, 없을 수도 있습니다. 보안접속 프로그램을 담은 ActiveX의 경우, 실제
로 그 보안접속 프로그램이 수행하는 역할은 SSL 과 대동소이 하지 않나요? 심지어 소프트포럼의 보안접속 플러그인은 아예
"SSL 접속을 하기 위한 것"이라고 적혀 있던 것으로 기억합니다. -이니텍은 조금 다른 것도 같습니다만, 어쨋건,
shared key 를 비대칭 암호화 방식으로 전달하고, 상대방이 이것을 복호화하고 나면, 그 순간부터 세션이 끝날때 까지 이
shared key 를 가지고 대칭 암호화한 정보가 네트웍을 오가는 원리는 SSL 과 같다고 저는 이해합니다.
다만, SSL/TLS 보안접속과의 차이점은 shared key 가 서버-클라이언트 간에 공유되는 구체적 절차에 대한
documentation 이 (국내에서 사용되는 보안접속 프로그램의 경우에는) 전혀 없으므로, 그 위험여부를 객관적으로 검증해
볼 수 없다는 것 정도로 저는 생각하고 있습니다.
> > 인터넷 뱅킹이야 말로 그 무엇보다도 가장 최선의 보안대책이 구현되어야 하는 보안이 가장 중요한 사회적 행위임이 분명한데..
> > 그러한 보안의 중요성 보다는 당장 웹 표준화, ActiveX 제거만을 외치는 부분이 안타깝습니다.
선생님께서 적으신 이 부분은 실은, 두개의 논점이 포함되어 있습니다.
1. 오픈웹은 그동안 “ActiveX 만을 사용하고, 다른 어떤 대안도 제공하지 않는 서비스 제공 행태”에 대하여는 단호하고 분
명하게 반대 입장을 취해 왔습니다. 그런 행태는 다양한 소프트웨어들 간의 자유로운 경쟁과 소비자의 선택권을 원천적, 일방적으로
말살하기 때문입니다. 웹브라우저 소프트웨어 선택권은 user 에게 있어야 하는 것이지, 서비스 제공자가 user 의 선택권을 일
방적으로 말살하는 것은 옳지 않다고 생각합니다.
2. 그러나, “보안 기술적 측면”에만 국한 할 경우, 오픈웹의 입장은 ActiveX 라는 ‘틀’에 담긴 어떤 프로그램이 보안
에 도움이 되는 부가프로그램일 수는 있지만, 보안을 위한 그런 부가 프로그램을 무작정 ActiveX 라는 틀에 담아서 배포하는
것은 모순적일 수 있다는 것입니다. 선생님께서도 지적하셨듯이, 대부분의 경우, 액티브X는 오히려 보안과는 무관한 맥락에서 사용됩
니다(웹서버가 제공하는 pdf 문서를 '읽기'위해서, 웹서버가 주는 동영상 파일을 그저 '재생'하기 위하여 등, 로컬 리소스에
대한 액세스와는 전혀 상관없는 맥락). 액티브X는 그런 맥락에서 이용자의 사용 경험을 풍부하게 하는 용도로 사용하는 것이 바람직
하다는 것이 제 생각입니다.
액티브X가 "일반적으로" 보안 위험을 초래할 "잠재성"이 큰 기술이라는 사실은 MS사 스스로도 인정하고, 그 배포과정을 점진적으
로 더 까다롭게(user intervention을 더 많이 요구하는 방식으로) 변경시키고 있지 않습니까?
액티브X가 "보안"을 위하여 반드시 필요하다는 견해는 저는 잘 이해가 어렵습니다. 그 속에 담기는 어떤 프로그램이 보안에 유용
한 것이라는 점을 알겠는데, 그와 대등한 기능이 이미 웹브라우저에 built-in 되어 있다거나(보안접속의 경우), NPAPI
형태로 그 프로그램을 구현해도 되는데(전자서명의 경우), 굳이 ActiveX 라는 '틀'을 고집하는 것이 잘 이해가 안되어 자
꾸 물어보는 것입니다. 그 '틀'이 보안을 제공하는 것은 아니지 않습니다. (틀 속에 담긴 프로그램이 보안을 제공하고, 그 프
로그램은 덜 위험한 틀에 담아서 사용할 수도 있는데...)
youknowit
> 액티브X가 "보안"을 위하여 반드시 필요하다는 견해는 저는 잘 이해가 어렵습니다. 그 속에 담기는 어떤 프로그램이 보안에 유용
> 한 것이라는 점은 알겠는데, 그와 대등한 기능이 이미 웹브라우저에 built-in 되어 있다거나(보안접속의 경우), NPAPI
> 형태로 그 프로그램을 구현해도 되는데(전자서명의 경우), 굳이 ActiveX 라는 '틀'을 고집하는 것이 잘 이해가 안되어 자
> 꾸 물어보는 것입니다. 그 '틀'이 보안을 제공하는 것은 아니지 않습니까? (틀 속에 담긴 어떤 '프로그램'이 보안을 제공하고, 그 '프
> 로그램'은 덜 위험한 '틀'에 담아서 배포, 사용할 수도 있는데...)
youknowit
로그인 직전 단계에서는 익명사용자 SSL 접속세션(anonymous SSL session) 이 이루어집니다. 스크린 샷 참조.
http://groups.google.com/group/open-web/web/softforum_SSL_plugin.png
로그인이 이루어지면, 클라이언트가 확인된 세션(client authenticated SSL session) 이 형성됩니다. 스크
린 샷 참조. http://open-web.googlegroups.com/web/softforum_SSL_client_authenticated_session.png
저는 도무지 어째서 "SSL 이 더 안전하냐, ActiveX가 더 안전하냐"는 식의 논란이 이토록 소모적으로 벌어지는지를 이해
할 수 없습니다. 보안전문가 분들께서는 이미 아시고 계실 것이 아닙니까, ActiveX 플러그인 중에는 "실은 SSL 을 구현
할 목적으로 사용되는 것"들도 있다는 사실을... 이런 ActiveX 플러그인이 어째서 필요하다는 말씀이신지요?
(그리고, 소포가 사용하는 SSL 이 SSL2인지, SSL3 인지도 어느 분이 좀 말씀해 주시면 좋겠습니다. 저같이 업계 관련자
가 아닌 일반인들은 도저히 알 방법이 없네요. Documentation 이라도 좀 속 시원히 있었으면 좋으련만...)
정 태영
인터넷 익스플로러용 확장기능을 구현하기 위한 방법이 ActiveX(DCOM
Component)이고, 모질라 계열 브라우져(+Konqueror)의 확장기능을 구현하기
위한 방법이 NPAPI 인 걸로 알고 있습니다.
둘다 내재되어 있는 위험성은 동일하므로 NPAPI로 배포되느냐 혹은 ActiveX
로 배포되느냐로
위험성 여부를 판단할 수는 없을 것 같습니다.
실제 Flash plugin만 보더라도 Internet explorer를 위한 ActiveX와 Firefox
를 위한 NSPlugin을 따로 배포하고 있고, 둘 중 하나만 설치할 경우 다른 브
라우져에서는 플래쉬를 볼 수 없죠.
그리고 계속 되풀이되는 얘기지만 SSL Sniff, strip과 관련된 내용은 ActiveX
를 사용한다고 막을 수 있는 문제들이 아니라고 판단됩니다. 비슷한 문제를
가지고 있다면 크로스 브라우징을 지원할 수 없는 방법보다는 크로스 브라우
징을 지원할 수 있는 있는 방식을 체택하는 것이 더 좋을거란 얘기죠.
대신 보안 채널 만으로는 원하는 정도의 보안 레벨을 제공할 수 없을테니 보
안카드, 공인인증서 등의 2차적 보안 장치를 사용하고, 키보드 해킹, 바이러
스 등에 취약한 운영체제에 대해선 사용자가 선택적으로 보안 툴을 적용할
수 있음 좋을 것 같습니다. (Ex: 다음 로그인 화면의 보안접속, 해킹방지 옵
션 네이버 로그인 화면의 1, 2, 3단계 보안 레벨) - 참고로 공인인증서를 이
용하여 값들을 서명하게 될 경우 중간에서 내가 보낸 값을 변조하는게 불가능
해집니다. 단 공인인증서가 ssl 채널 하에 전송될 수 있다는 점(처음 발급받
을 경우) 때문에 문제가 될 수 있겠네요.
게다가 지금 윈도우 실정에 맞게 구성되어 있는 보안 툴들을 그대로 타 플랫
폼에까지 적용하려고 하니까 심사를 통과할 수가 없는 실정인데...
http://news.zdnet.com/2100-9595_22-251586.html
위 링크는 작년 말에 zdnet에 실렸던 기사입니다. 제 기억으로는 torrent로
배포된 iLife에 해킹 툴이 심어져있었던 사건으로 기억되는데, 윈도우 세계에
서 저정도 일이라면 뭐 대수롭지 않게 넘겼겠죠. 워낙 흔한 일이니. 하지만
Mac OS X 에서는 저런 일이 절대 흔하지 않은 일이었던 겁니다. 리눅스도 거
의 마찬가지 상황이죠.
이런 OS 환경과 (일반적으로 초심자들에 많이 노출되어서 이런 결과가 나오
고 있겠지만) 윈도우 환경을 동일한 선상에 놓고 동일한 것들을 막아야한다는
건 조금 어폐가 있다고 생각합니다. 백신, 키보드 보안 툴들을 맥, 리눅스 환
경에 까지 강요하는 것은 피해줬음 좋겠다는 얘기죠.
2009. 04. 12, 오후 11:34, youknowit 작성:
youknowit
> 인터넷 익스플로러용 확장기능을 구현하기 위한 방법이 ActiveX(DCOM
> Component)이고, 모질라 계열 브라우져(+Konqueror)의 확장기능을 구현하기
> 위한 방법이 NPAPI 인 걸로 알고 있습니다.
>
> 둘다 내재되어 있는 위험성은 동일하므로 NPAPI로 배포되느냐 혹은 ActiveX
> 로 배포되느냐로
> 위험성 여부를 판단할 수는 없을 것 같습니다.
네, 둘 다가 플러그인 이라는 점에서는 비슷한 위험 요인이 있지만, 윤석찬님께서 지적하신 것 처럼, npPlugin 의 경우 웹
브라우저가 Sandbox 역할을 합니다. 그래서 위험성이 ActiveX 플러그인과 "동일하다"고 하기는 어렵지 않나요?
http://groups.google.com/group/open-web/browse_thread/thread/cefbaf8e595c116d/8cab669b56e7fc1b
물론, 제가 적은 것 처럼, npPlugin 형태로만 전자서명 플러그인을 배포, 사용할 경우, MS IE로는 인터넷 뱅킹을 못하
게 되는 반면, 파이어폭스, 크롬, 오페라 등 npapi 프러그인을 지원하는 다양한 웹브라우저는 모두 사용이 가능하게 됩니다.
전국민의 99%에 설치되어 있는 MS IE 를 뱅킹에 사용하지 못하게 한다는 것이 말이되냐? 라고 반문하실 것입니다. 그러나,
100%의 국민이 파이폭스나 크롬 등을 설치할 수는 있습니다. 그 설치가 과연 현재 은행들이 설치를 강요하는 ActiveX 플러
그인 설치 보다 "비현실적으로 어렵거나 번거로운가"는 논의해 볼 만한 이슈라고 생각합니다. 설치에 필요한 "클릭 수"는 비슷합니
다. (은행들이 아예 "파이어폭스 설치 ActiveX"를 배포할 수도 있긴 하지요)
물론, 지난 10년간 다른 웹브라우저를 못쓰게 막는 것은 당연히 여기면서도, MS IE 를 못쓰게 하는 것은 결코 용납 못하는
분들이 대부분일 것입니다. 그분들의 논거는 실은 "보안"이 아닙니다. "뱅킹에서는 보안이야말로 지상의 가치"라고 말씀은 하시지
만, 실은 보안이 아니라, 다수의 이용자들이 그저 MS IE 를 사용한다는 "현실"을 더 중요한 가치로 두고, "비록 보안에는
상당한 양보를 해야 하지만" 그냥 ActiveX 를 쓰는 것입니다.
"보안이 지상가치이므로 ActiveX 를 써야만 한다"는 반복되는 담론은 적지 않은 "허구"를 담고 있다는 점을 부각시키기 위하
여, NPAPI 이야기를 꺼냈습니다. 진정으로 보안이 지상 가치라면, 그리고, 플러그인을 어쩔 수 없이 써야 하는 상황이라면(전
자서명은 플러그인 없이 안되니), npPlugin 을 선택하는 것이 논리적으로는 옳지 않겠습니까? ActiveX 보다는
npPlugin 이 "보안상으로는" 덜 위험하니까...
파폭 설치는 2-3분이면 끝나지 않나요?
Channy Yun
사용될 수도 있기 때문에 잠재적인 문제는 여전히 가지고 있습니다.
http://www.iol.ie/~locka/mozilla/plugin.htm
위의 프로젝트가 아주 오래 오픈 소스로 진행되고 있음에도 모질라 커뮤니티에서
인정하지 않는 것도 이런 요인 때문에 그렇습니다.
Channy
On 4월13일, 오전12시44분, youknowit <keechang....@googlemail.com> wrote:
> On 4월13일, 오전12시08분, 정 태영 <mas...@mytears.org> wrote:
>
> > 인터넷 익스플로러용 확장기능을 구현하기 위한 방법이 ActiveX(DCOM
> > Component)이고, 모질라 계열 브라우져(+Konqueror)의 확장기능을 구현하기
> > 위한 방법이 NPAPI 인 걸로 알고 있습니다.
>
> > 둘다 내재되어 있는 위험성은 동일하므로 NPAPI로 배포되느냐 혹은 ActiveX
> > 로 배포되느냐로
> > 위험성 여부를 판단할 수는 없을 것 같습니다.
>
> 네, 둘 다가 플러그인 이라는 점에서는 비슷한 위험 요인이 있지만, 윤석찬님께서 지적하신 것 처럼, npPlugin 의 경우 웹
> 브라우저가 Sandbox 역할을 합니다. 그래서 위험성이 ActiveX 플러그인과 "동일하다"고 하기는 어렵지 않나요?http://groups.google.com/group/open-web/browse_thread/thread/cefbaf8e...
youknowit
서명 플러그인을 ActiveX로 배포할 경우에는 반드시 관리자 권한이 있어야 설치가 가능한 것 같은데, 이것이 맞는지?
그리고, 통상의 npPlugin 의 경우, 일반 사용자 권한으로도 설치가 가능한 것 같은데, 전자서명 기능을 가진
npPlugin 도 일반 사용자 권한으로 설치 가능한지? (서명된 자바 애플렛 형태의 signer plugin 은 당연히 일반
사용자 권한으로 실행이 가능하다는 점은 알고 있습니다만, npPlugin 도 그런지는 잘 모르겠습니다)
On Apr 13, 1:32 am, Channy Yun <cha...@gmail.com> wrote:
> 여기서 고려해야 할 점은 기존의 npplugin 방식도 윈도우에서는 activex launcher로
> 사용될 수도 있기 때문에 잠재적인 문제는 여전히 가지고 있습니다.http://www.iol.ie/~locka/mozilla/plugin.htm
skon
이 운동의 핵심은 정치적인 접근입니다. 정치적으로 좀 공정해지자는 뜻입니다.
그런데 주위에서는 자꾸만 경제적인 면을 보라고 합니다. 구축 비용의 문제이며, 해킹됐을 때 손해보게되는 비용, 대외 신용(이것
도 결국은 경제적인 관점이랄 수 있겠죠.)의 문제라는 뜻입니다.
하지만, 이런 주장은 결국 정치적인 공정함을 무시하게 됩니다.
정치적 공정함을 생각할 때, 흔히 생각나는 것으로 장애우들이 있습니다.
장애우들이 보통 경제적으로 도움이 되기보다는 보통 손해를 끼치고 불편을 줍니다. 하지만, 인간의 존엄성을 기초로 정치적인 공정함
을 적용해, 어찌보면 낭비에 해당할 수 있는 그들에 대해서 특별히 배려하고 그들을 위해 불편을 감수합니다. 왜 그럴까요.. 장애
우도 우리 나라의 한 구성원이며 (구성비율이 낮음에도 불구하고) 인간으로서 누려야할 혜택이 필요한 존재이고, 그 혜택은 다른 사
람에 대해 좀더 특별해야하기 때문입니다.
이러한 상황은 우리나라의 인터넷 사용환경과 비슷한 면이 많습니다. 1% 정도일지 모르겠지만, 윈도우 환경이 싫어 다른 방법을 찾
아본 사람들입니다. 저 또한 주력 컴퓨터로 FreeBSD를 7년 정도 쓰다가, 3년 정도는 맥을 써온 사람입니다. 그런데, 정
부 홈페이지, 은행에 들어갈려면 윈도우밖에 방법이 없습니다.
(개발자분들 중에 1%에 불과한 이용자를 위해 별도의 비용과 시간을 들이는 것은 불합리하다는 생각을 가지신 분들이 너무 많습니
다. 또한 가끔 비윈도우 사용자도 어떤 방법으로든 은행을 이용해왔으니 문제될 것 없다는 주장을 하시는 분도 계십니다. 블로그나
게시판에 당당히 이런 불만을 얘기하시던 분들을 많이 봐왔습니다. 그런데 그런 발언들은 정말 비윈도우 사용자에게 무례한 것입니
다. 사람이란 자기 의결권을 가지고 있습니다. 그걸 강제할 때 사람들은 심한 모멸감을 느낄 수밖에 없습니다. 정말 어쩔 수 없
이 무기력하게 쓰는 것이지, 쓰고 싶은 것이 아닙니다.)
이런 제반의 환경에서 오픈웹의 운동방향은 단순히 캠패인 수준에서 진행될 수 없었다고 봐야할 것입니다. 그렇다고 해서 캠페인을 안
한것도 아닙니다. XP SP2에서의 ActiveX 정책 변경, 비스타의 ActiveX 정책 변경, IE8에서의 ActiveX 정
책변경과 같은 굴직굴직한 이슈에서 끊임없이, "봐라 너무 종속된 환경에 의존하는 경우 문제가 많이 발생할 수 있다. 좀더 표준적
인 환경으로 가자"라고 주장해왔습니다. 그러면 뭐합니까? 3년간의 중요이슈에서 현재까지 온 길은 오직, 윈도우, IE에서의 보안
강화였습니다.
이 굴직굴직한 사안들이 터졌을 때, 전문가 집단 어느 누구도 다른 길도 있으니 그 길을 마련해보자는 얘기나 그 시도는 없었습니
다. ActiveX는 여전히 사용가능하다라는 식으로는 접근했습니다. ActiveX가 꼬졌다가 우선이 아니라 한 회사의 정책에 더
이상 그만 휘둘리자는 겁니다.
전문가라면 전문가라는 자부심과 전세계 시장의 흐름을 얘기하고 싶다면 시장성이 없다라도 앞으로 무엇을 어떤 식으로 개선해나갈 수
있는가라는 제안이라도 좀 제시했어야하는 거 아닐까요? 왜 전문가 집단도 아닌 오픈웹에서 우리 주장에 기술적으로 완비된 해결책을
제시해야할까요. 이건 오히려 전문가집단에서 이런 식으로 하면 가능할 수 있다라는 시안을 주고 이 시안으로 오픈웹이 정부와, 은행
과 협상해야했던 것이 아닐까요?
지금도 지속되고 있습니다만, 과거 과학과 정치, 경제 등과의 연관성에 대한 많은 고민들이 있었습니다. 그리고 많은 과학자들이 반
성하기도 했습니다. 과학의 발전은 결코 정치, 경제와 독립적이지 않았고 거기에 피해를 받은 많은 사람들이 있었습니다. 작금의
ActiveX 사태또한 이런 문제가 있다고 생각합니다. 너무나도 경제 논리에 휘둘려 이에 소외되는 사람들이 많다는 점을 무시하
고 있습니다... 전문가 여러분... 조금은 더 정치적인 공정함으로 이 기술을 바라봐주셨으면 합니다.
사족.
"예" 이론은 많은 부분에서 지적될 수 있는 부분이기는 하지만, 역설적으로 "아니오"를 누룰 필요가 있음을, "아니오"를 누루
는 훈련을 의도적으로 시켜야함을 얘기하고 있다고 생각합니다. 인간은 어쩔 수 없이 "예"를 누루기 싶습니다. 다른 사람의 질문
에 부정적으로 시작하는 사람이 얼마나 될까요?
하지만, ActiveX의 역사는 MS에게 영광이기도 했지만, 질곡의 역사이기도 했습니다. XP SP2에서 왜 굳이 "예", "아
니오"를 넣었겠습니까.. 생각좀 하고 설치해라라는 거 아니었던가요? 서비스가 완비되지 않더라도 아니라고 생각하면 내가 원하지 않
는다면, "아니오"를 눌러라는 뜻 아닌가요?
보안 프로그램 설치시에 이런 선택권이 있나요? 키보드 보안 프로그램, 백신 프로그램... 거절하면 큰일난다는 소리는 있어
도... 안깔아도 쓸 수는 있지만, 너 위험해라는 선택권은 있던가요?
인간은 선택할 수 있는 권리가 있고, 그 권리를 행사했을 때, 책임을 질 의지도 있습니다. 이용자를 바보취급하기 이전에 이용자에
게 충실한 정보와 선택권을 주고 있는지도 생각해주셨으면 좋겠습니다.
어떤 분께서 일본에서도 ActiveX를 이용한 기술을 쓰려고 한다면서, 얘기하신 것이 일본사람들은 잘 안쓰려는 경향이 있다라고
언급하셨습니다. 우리나라는 당장 이런 학습과정이 필요로 합니다. 우리나라는 "아니오"를 누르게하는 일체의 학습과정이 없었습니
다. 무조건 "예"만 누르라고 합니다.
다시한번 말하지만, 오픈웹에서 주장하는 "예"이론은 그게 맞다, 틀리다를 떠나서 "아니오"를 누르게하는 학습이 필요함을 역설한다
고 생각합니다.
사족 2.
ActiveX를 자꾸 지적하는 것은 좀 다른 길을 알아볼 사람은 없냐라는 질문이기도 합니다.
자꾸만 ActiveX가 좋다는데.. 이런 문제가 있으니까 다른 길좀 알아보자라고 한 겁니다.. 그거에 ActiveX 꼬진 게 아
니다라고 얘기하는 것은 별 의미가 없습니다. 압니다.. ActiveX 좋은 거.. 그렇지만, 문제가 있다는 겁니다.
검은 그냥 도구일 뿐입니다. 그걸 사과껍질 깔 때 쓸 수도 있고, 사람 죽이는데 쓸 수도 있습니다.
다만, 사람들이 이러한 도구가 어떻게 쓰여왔는지의 역사를 알고 있습니다. ActiveX 또한 좋은 기술인 거 압니다. 다만,
그 역사가 안좋은데 쓰인 적이 너무나 많음을 알고 있는 것입니다.
그러면 그러한 역사를 가진 놈을 어떻게 관리하냐고요? 아무렇게나 쓰게 나두지 않습니다. 칼집에서 검을 꺼내는 순간을 생각해보세
요.. 상당히 제한된 상황에서 쓰게 하는 거죠.. ActiveX도 그러했습니다. MS의 일련의 조치를 생각해보십시오.
우리나라의 ActiveX는 이런 조치에 정면으로 반발했습니다. 하다못해 Vista에서의 작동을 생각해보면 MS의 기본 정책조차
무시하라고 합니다.
사족 3.
말 주변머리가 없어서.. 정리가 안되는 점 죄송합니다.
skon
정확히 말해서 iWork '09 버전입니다.
정품에는 없었고, 인터넷에 불법으로 올려진 버전에 trojan이 심어져있었습니다.
http://www.macworld.com/article/138412/2009/01/trojan.html
swlee
하던, 통채로 암호화 하던 기술적으로 가능하며 통채로 암호화하는 것이 FORM DATA 의 악의적인 위변조를 막는데 효과적입니
다.
예를들어 계좌번호가 12345678 이라면 SSL 만 적용되어 있다면 간단한 SSL 터널링 기법을 이용하여 손쉽게 위변조를 시도
해야 겠지만 E2E 보안 기술이 적용되어 있다면 우선 암호하 로직 부터 뚫어야 겠죠...
또 기술적으로 서버에서 E2E 자체적으로 클라이언트 DATA의
무결성 검증등이 가능하기 때문에
얼마든지 앞으로도 추가 개발을 통해 보안을 향상시켜나갈 여지가 많지만
SSL은 웹서버에 SSL 인증서 설치, 웹소스에서
링크를 https 수정 이외에는 할 수 있는것이 없습니다.
지속적으로 증가하는 보안 위협에는 택도 없는 노릇이죠..
했던말 또하고,,또하고.. 이젠 힘드네요..
여기있는 분들이 단순 이론적인 논리로만 말씀하시는데..
실제 구현된 로직을 분석해 보시고 OWASP 웹 10대 취약점을 기반으로
비교해 보시면 어느방법이 실제로 나은지 알 수 있을 것입니다.
교수님이 말씀하신 인터넷 뱅킹 취약점 역시
논리와 간단한 문서, 나머지는 말을 통해 이러이러한 식으로가능할 것이다 가 아니라
실질적으로 샘플 환경을 구현해 보시고 취약점을 시뮬레이션 한 다음에
XXX 한 논리는 이래서 가능하고 ZZZ 한 점은 불가능 하다 하시면
누구나 충분히 공감하고 이해할 수 있을 것이며
더이상 억지라고 말하지 않을 것입니다.
최소한 그 정도는 되어야 남을 설득하고,
자신의 주장이 옳다고 예기할 수 있는 수준의
근거가 될 수 있을 것입니다.
> > > 로그램은 덜 위험한 틀에 담아서 사용할 수도 있는데...)- 따온 텍스트 숨기기 -
>
> - 따온 텍스트 보기 -
swlee
현재 적용되어 있는 SSL은 서버를 인증하는 것입니다.
상호 인증이 있기는 하지만 일반적인 웹 서비스에서 상호인증을 구현하는 경우는 없습니다.
그래서 얼마든지 로컬에서 SSL 프록시 프로그램을 가동하여
SSL 터널링을 하더라도 서버는 전혀 알아 차릴 수가 없는 것이죠..
키교환및 암호화는 SSL 프록시 서버에서 알아서 다 하니까요..
클라이언트가 DATA를 위변조 했다는 사실을 전혀 알 수 없습니다.
반면 E2E는 이러한 프록시의 개념을 적용할 수 없습니다.
따라서 많이 언급된 MITM 같은 네트워크 공격도 불가능 하고요..
눈에 보이는 것이 비슷하다고 같은것이 아닙니다.
보고싶은 것만 보려고 하지 마십시요..
> > - 따온 텍스트 보기 -- 따온 텍스트 숨기기 -
정 태영
http://demo.initech.com/?module=file&act=procFileDownload&file_srl=2183&sid=5c5c303c7a32e863ee9403ae49ad4da2
하단에 표시되는 페이지 기준으로 37, pdf 에서의 페이지 기준으로 39 페이지
에 해당 내용이 정리되어 있네요.
보니 키보드 보안 모듈에서 키값->암호화 ... 서버단에서 복호화->키값 식의
방식을 사용하여 E2E 보안을 이뤄낼 수 있다. 라고 얘기하는 것으로 보이는데
요. ('E2E Xecureweb' 으로 구글링 했을 때의 결과가 이해가 가네요.)
그렇다면 이는 암호화 모듈 즉 SSL과 대치 해줬음 하는 부분과는 관계가 없어
보입니다.
2009. 04. 13, 오전 9:21, swlee 작성:
youknowit
아마 글타래가 달라서 못보신 것 같습니다. 제가 제시한 취약점 공략방법에 대하여 dasony 님께서도 선생님과 유사한 지적을 하
셨는데, 저는 조금 달리 생각하고 있습니다. 제 생각은 여기에 적어보았습니다.
http://groups.google.co.kr/group/open-web/msg/34fc05eef7a986f0?hl=en
e2e 보안은 고객-서버 간 교신 구간에서 이루어지고, 말씀하신대로 서버가 무결성을 점검할 수 있다는 점에서 단순 키보드보안과
는 크게 다르다고 저도 이해하고 있습니다. 하지만, 제가 제시한 방법에서 공격자는 "진짜고객"으로서 은행과 교신하므로, e2e
보안은 문제가 되지 않는다고 생각합니다. 공격자--서버 간의 교신 integrity 는 전혀 공격하거나 건드릴 필요가 없습니
다. 고객과 공격자 간에 plaintext 로 이루어지는 http pipeline 만을 하나 추가하는 것이기 때문입니다. 링크
해 드린 글을 한번 보시고 오류를 지적해 주시면 즉시 수정하겠습니다.
swlee
던 것과 다를바가 없네요..
아래는 www 프록시를 통한 ssl 터널링을 예기하고 있습니다.
http://muffin.doit.org/docs/rfc/tunneling_ssl.html
이러한 개념이 ete 모델 에도 적용이 가능한지 알려주세요..
즉 중간의 프록시에더 평문 데이터의 스니핑이 가능하고 위변조가 가능한지
말씀해 주시면 저역시 두 보안 기술 모델에 차이가 없음을 인정 하겠습니다.
On 4월13일, 오전9시54분, 정 태영 <mas...@mytears.org> wrote:
> 말하시는 E2E 보안 접속 기술에 대해 찾아봤습니다.
>
> http://demo.initech.com/?module=file&act=procFileDownload&file_srl=21...
>
> 하단에 표시되는 페이지 기준으로 37, pdf 에서의 페이지 기준으로 39 페이지
> 에 해당 내용이 정리되어 있네요.
>
> 보니 키보드 보안 모듈에서 키값->암호화 ... 서버단에서 복호화->키값 식의
> 방식을 사용하여 E2E 보안을 이뤄낼 수 있다. 라고 얘기하는 것으로 보이는데
> 요. ('E2E Xecureweb' 으로 구글링 했을 때의 결과가 이해가 가네요.)
>
> 그렇다면 이는 암호화 모듈 즉 SSL과 대치 해줬음 하는 부분과는 관계가 없어
> 보입니다.
>
> 2009. 04. 13, 오전 9:21, swlee 작성:
>
>
>
> > 아마 오픈웹의 가장큰 오해는 E2E 보안접속 기술이 통채로 암호화 하여 다
> > 를바가 없다라고 말씀하시는 것 같습니다. 일부를 암호화
> > 하던, 통채로 암호화 하던 기술적으로 가능하며 통채로 암호화하는 것이
> > FORM DATA 의 악의적인 위변조를 막는데 효과적입니
> > 다.- 따온 텍스트 숨기기 -
dasony
부분은 이미 나온 이야기고, 잘 사용하지는 않지만 이미 모든 브라우저에 탑재되어있는 SSL의 Client Certificate
이용시 동일한 효과를 볼 수 있다는 이야기도 나온 이야기입니다. 인터넷 뱅킹은 일반적인 웹서비스가 아니라 상호인증 구현해서 해야
한다고 생각합니다. =)
다른 쓰레드에서 나온 MITM 공격은 ActiveX 자체를 변경하는 방식이기 때문에, SSL터널링과 거의 흡사한 방식으로 공격
이 가능할 것으로 보고 있습니다. 말로만 하지 말고 실제 시뮬레이션을 해보는 것이 좋다는 부분은 동의하지만, 다들 생업이 있으
신 분들이라 말로밖에 못하는 상황을 좀 이해해주셨으면 합니다. ^^;
다만 ActiveX는 웹브라우저 기능을 사용하는 것에 비해, 자체적인 지속적인 대응이 가능하다는 부분은 확실한 장점입니다. 꼭
그렇게 해야 하나 싶긴 하지만요.
swlee
상호인증을 하면 좋긴 좋지만..
상호인증을 하더라고 공격자는 정상적인 클라이언트 인증서 하나만 받으면 됩니다. 별로 어려운 일이 아닐 듯 하네요.. 즉 상호 인
증 역시 프록시 서버를 이용하여 MITM 하는것이 가능하며 기본적인 SSL의 문제점을 극복할 수는 없습니다.
그리고 ActiveX 는 http form data의 암복호화만을 담당할뿐 HTTP Request 를 전송하거나 하는 행위는 없
습니다. 프록시의 개념은 아닙니다. 클라이언트 측에서 전송과 수신은 모두 브라우저가 처리합니다.
그리고 교수님의 이론은 제가 짧아서 그런지 잘 이해조차 되지 않습니다.
머라고 드릴 말씀이 없습니다.
swlee
공격자는 악의적인 ActiveX 를 Victim 클라이언트 PC 에 설치를 한다는 전제가 필요합니다.
여기계신 보안 전문가들이나 제가 예기하는 문제점에는
클라이언트 PC 에 악성 프로그램을 설치한다는 전제로는 예기하지 않습니다.
사실상 클라이언트 PC 에 공격자가 의도하는 악성코드가 설치되었다고 전제를 하면
못할것은 이미 아무것도 없으며 어떠한 방법을 적용해도
모두 가능하다고 말씀 드리고 싶습니다.
이미 해킹 완료라고 보셔도 무방할 수준입니다.
> > 그렇게 해야 하나 싶긴 하지만요.- 따온 텍스트 숨기기 -
youknowit
http://groups.google.co.kr/group/open-web/web/%ED%95%9C%EA%B5%AD+%EC%9D%B8%ED%84%B0%EB%84%B7+%EB%B1%85%ED%82%B9+%EB%B3%B4%EC%95%88%EC%9D%98+%EC%B7%A8%EC%95%BD%EC%A0%90?hl=en
그리고, 언급하신 ssl 터널링은 HTTPS transparent proxy 를 어떻게 구현하는지에 대한 개요 설명인 것으로 저
는 이해하고 있습니다. https proxy 의 경우, 프록시는 오가는 데이터를 복호화할 수도 없고, 내용을 변조할 수도 없는
것으로 이해합니다. "When tunneling SSL, the proxy must not have access to the
data being transferred in either direction, for sake of security." 당연
한 내용이라고 생각합니다. 만일 그렇지 않다면 "https" proxy 는 불가능할 것입니다.
"SSH 터널링"과 정 반대의 개념이라고 저는 이해하는데. 즉, SSH 터널링은 암호화된 파이프라인을 만들고 , 그 속으로 평
문 교신이 통과하도록 하는 것이고, HTTPS 터널링은 평문 파이프라인을 만들고, 그 속으로 암호화된 메시지들이 통과하도록 하
는 것 아닌가요?
제시하신 글은, 프록시 공격이 가능하다는 내용은 아니고, 그런 식으로 프록시를 설계하면 HTTPS 교신도 프록시 서버를 통하여
안전하게 이루어질 수 있다는 점을 설명하는 것이라고 저는 이해하고 있습니다만...
Jung Tae-young
닌가요? 앞에서 얘기가 많이 나왔던 SSL Strip, SSL sniff 가 대입되지 못할
이유가 없어보입니다.
프로토콜이 공개되어 있진 않지만 비트 단위 출력이 나오는 alz 도(zip 과 유
사하다는 정보만으로) 리버스 엔지니어링 해서 디코더를 만드는 판에 이 프로
토콜을 리버스 엔지니어링 못한다는건 말이 안된다고 봅니다.
단 *정말 상호 인증을 사용하고*, *유효하지 않은 인증서를 자동으로 거부한
다*면 MITM 식으로 중간에서 고객으로 가장하고 서버와 통신하는 문제는 피해
갈 수 있을 것이라 보입니다. [1]
하지만 SSL strip 의 변형 공격이 불가능할 것으론 생각되질 않습니다.
https:// 식의 링크를 http:// 로 변경해서 보내주는게 가능하다면 activeX
를 이용하는 javascript를 변조해서 보내는 것 또한 어렵지 않겠죠.
[1] 질문: MITM 에서 유효하지 않은 인증서 오류를 피하는 방법이 CA 값이
FALSE인 인증서(다른 인증서를 서명할 권한이 없는 인증서)를 사용해서 사인
하는 방법 외에 또 다른게 있나요?
아래 문서에 따르면 관련된 문제는 IE6 이하 버젼에 한정된 것으로 보이니 만
약 저 문제 외에 다른 방법이 없다면 IE6 이하 버젼으로는 인터넷 뱅킹을 하
지 못하도록 하는 것으로 피해갈 수 있을 것으로 보이는데요.
http://www.thoughtcrime.org/ie-ssl-chain.txt
swlee 쓴 글:
> 어플리 케이션 레벨의 암호화(http 소스 레벨) 와 네트워크 레벨에서 패킷을 모두 암호화 하는것의 차이가 별반 없다고 예기했
> 던 것과 다를바가 없네요..
>
> 아래는 www 프록시를 통한 ssl 터널링을 예기하고 있습니다.
> http://muffin.doit.org/docs/rfc/tunneling_ssl.html
> 이러한 개념이 ete 모델 에도 적용이 가능한지 알려주세요..
>
> 즉 중간의 프록시에더 평문 데이터의 스니핑이 가능하고 위변조가 가능한지
> 말씀해 주시면 저역시 두 보안 기술 모델에 차이가 없음을 인정 하겠습니다.
>
>
--
오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다.
youknowit
기 어려운 공격이라면, 그것은 이미 심각한 보안위협이라고 보아야 하지 않을까 생각합니다.
클라이언트 PC에 악성프로그램이 설치되지 않았다고 전제하고 이야기 한다면, 실은 키보드보안 프로그램 자체가 필요가 없겠지요.
키보드 보안(e2e가 되었건, 단순 안티 키로거가 되었건) 프로그램의 유일한 존재이유가 바로 사람들의 컴퓨터에 악성프로그램이 설
치되어 있고, client workstation 의 integrity 가 깨져있는 경우가 많다는 사실 아닌가요?
지금 이순간에도 사람들이 자꾸 악성프로그램 설치를 "수락"한다는 전제 자체를 부인하면, 아예 우리가 이런 논의를 할 필요도 없
을 것입니다.
사람들이 악성프로그램을 설치하더라도, e2e 보안은 높은 수준의 방어를 제공한다는 것인데, 제가 제시한 방법은 사람들이 "은행
사이트"와 외관과 URL이 완벽하게 동일한 상황에서 그 "은행"이 주는것으로 보이는 프러그인 하나를 "예"하면, e2e 보안이
되었거나, 보안카드 번호가 되었건 모두 무용지물이 된다는 것입니다.
http 접속으로 이루어지는 국내 금융거래의 "특성"을 고려하면, 이런 공격은 어쩔 수 없다고 체념하실 수는 없지 않겠습니까?
swlee
다.
raw http data야 평문이니 위변조를 못할 이유가 없습니다.
http://sandsprite.com/Sleuth/stunnel_sslRawreq.html
제 말이 이해가 되지 않는다면 참고 바랍니다.
지구인
구동되지 않는(최소한 가짜가 구동되는)것으로 보여 집니다.
그러니까 E2E는 서버와 공격자PC간에서만 있는것이고 사용자PC에는 공격자PC에 나타난 내용을
수정, 포워딩한 내용만 보여지는것 같습니다. 맞는가요?
사용자는 익숙한 페이지니 그냥 ID/PW를 입력 할것같고
그것을 그대로 받은 공격자는 자신 이 받은 페이지에 그 내용을 그대로 넣는 방식으로 보여 집니다.
E2E프로그램까지 가짜로 만들어서 공격자와 사용자간 가짜E2E를 구성 할 수도 있을것이구요.
이런 식이라면 MITM 과 별로 달라 보이진 않습니다.
E2E는 이런 방법을 막을수 있는가요?
역시 MITM과 E2E에 대한 정확한 이해를 제가 못하고 있을수도 있겠습니다.
지적 부탁 드립니다.
swlee
http raw data 를 ssl 암호화 하여 서버와 통신하는 기법을 다루고 있습니다.
http raw data는 평문이기 때문에 얼마든지 위변조가 가능하죠..
http://sandsprite.com/Sleuth/stunnel_sslRawreq.html
이것은 ssl 이 네트웍 구간에서 암호화 만을 보장하는 근본적인 한계를 반증합니다.
제 말을 이해 하시는데 참고 바랍니다.
> > > - 따온 텍스트 보기 -- 따온 텍스트 숨기기 -
swlee
http://sandsprite.com/Sleuth/stunnel_sslRawreq.html
위 링크는 raw http data 를 openssl 로 암호화 하여 서버와 정상적인 통신을 한다는 예기입니다.
raw http data 는 평문이기 때문에 위변조 하는것은 일도 아닙니다.
이것은 ssl 이 네트웍 구간에서 암호화 만을 보장하는 한계를 반증합니다.
dasony
> 상호인증을 하면 좋긴 좋지만..
> 상호인증을 하더라고 공격자는 정상적인 클라이언트 인증서 하나만 받으면 됩니다. 별로 어려운 일이 아닐 듯 하네요.. 즉 상호 인
> 증 역시 프록시 서버를 이용하여 MITM 하는것이 가능하며 기본적인 SSL의 문제점을 극복할 수는 없습니다.
현재 인터넷 뱅킹에서 사용하나느 공인인증서와 SSL의 Client Certificate를 동일한 것으로 봐야하지 않나요? 공격자
는 정상적인 클라이언트 인증서를 받을 수 없습니다. Client Certificate를 보고 어느 고객인지 확인하는 것인데요.
swlee
은행은 클라이언트 PC에서 사용해야할 인증서 파일을 지금의 공인 인증서 형태처럼 배포해야 할 것입니다.
그냥 인터넷 뱅킹 신청하면 공인인증서 받듯이 받을 수 있을 것 같은데요..
youknowit
> 현재 인터넷 뱅킹에서 사용하나느 공인인증서와 SSL의 Client Certificate를 동일한 것으로 봐야하지 않나요? 공격자
> 는 정상적인 클라이언트 인증서를 받을 수 없습니다. Client Certificate를 보고 어느 고객인지 확인하는 것인데요.
예, 저도 그렇게 알고 있습니다. 소프트포럼이 판매하는 보안접속 ActiveX 는 SSL 접속을 하기 위한 것에 불과합니다. 고
객이 공인인증서로 은행페이지에서 로그인 하면, 그때 부터는 "클라이언트 인증 SSL 세션"이 이루어집니다.
http://groups.google.co.kr/group/open-web/msg/383b949e821302f6?hl=en 에
링크된 스크린 샷 참조하시기 바랍니다.
여기 토론 하시는 분들은 이미 다 아시는 내용이겠지만...
dasony
방법은 없습니다. 즉 MITM 공격자가 은행에게 자신이 공격 대상이라고 속일 방법이 없습니다. Client Certificate
를 이용하여 로그인하는 서비스를 사용해보신 적이 없으신 것 같습니다. 많은 서비스들이 아이디/패스워드 없이 Client
Certificate만으로 로그인을 하여 사용합니다.
youknowit
국내에서 1000만장 넘게 발급된 공인인증서가 바로 client certificate 입니다.
"SSL 이 안전하냐, 별도 프로그램을 사용한 보안접속이 안전하냐"는 논의는 의미가 없습니다. 소프트포럼 등이 국내 은행에 납품
하여 지금까지 사용해 온 "보안 접속 별도프로그램"이 바로 SSL 교신(익명SSL 세션과 클라이언트 인증 SSL 세션)을 하기
위한 것입니다.
도대체 이런 플러그인이 왜 필요한지요?
Jung Tae-young
1. 아래쪽에서 얘기하신것: HTTP채널 - 데이터는 HTTP로 보내기 전에 암호화
2. 제가 얘기하는 것: 주고받는 내용이 SSL로 암호화된 HTTP (HTTP overl SSL)
3. 방금 얘기하신 것: SSL 을 지원하지 않는 클라이언트를 위한 wrapper
1번의 경우엔 현 ActiveX 체제의 암호화 통신을 들 수 있겠습니다. 데이터는
XecureWeb, INISafeWeb 등을 통해 암호화 되고 HTTP(over tcp) 혹은 TCP 등을
통해 전송됩니다.
2번의 경우엔 암호화를 ActiveX 등이 아닌 브라우져 자체에서 처리합니다. 브
라우져에서 기본으로 SSL을 처리하니까요.
1, 2 번에 대해서는 암호화의 주체(브라우져? ActiveX?), 그리고 프로토콜의
문서화/정형화 여부 밖에는 모르겠습니다.
3번의 경우엔 보내주신 문서보다 다음 문서에 더 잘 나와 있습니다.
http://www.stunnel.org/examples/generic_tunnel.html
간단히 얘기해서 HTTPS를 쓰고 싶은데, 클라이언트 브라우져가 HTTPS를 지원
하지 않는다면 stunnel 데몬을 띄우고 stunnel 을 통해서 https 서버로 접속
을 하게 되는 겁니다. imaps를 쓰고 싶은데, 내 메일 클라이언트가 imaps를
지원하지 않는 경우도 마찬가지
앞에서 간단해게 써놨는데...
1. 서버 - 공격자(고객으로 가장) 사이에 보안 채널이 형성되고,
2. 악의적인 ActiveX 혹은 ActiveX를 사용해서 보안 통신을 하는 것으로 가장
된 javascript 를 사용자에게 보내줄 경우 (SSL Strip과 비슷한 개념으로)
위/변조가 가능할 것으로 보인다는 얘기입니다..
제가 잘못말한 점이 있으면 지적 부탁드리겠습니다.
swlee 쓴 글:
swlee
제가 위에서 링크한 http raw data 를 위변조하는 공격은 소포의 보안 접속이 구현되어 있다면 근본적으로 불가능 합니
다.
이것은 네트웍 구간에서 암호화만을 보장하는 ssl의 근보적 한계입니다.
(http://sandsprite.com/Sleuth/stunnel_sslRawreq.html)
교수님은 applicaton 레벨에서 동작하는 해킹 기법과
이에 대응하는 암호화의 의미를 전혀 이해 하고 있지 못하고 있기 때문에
더의상의 논의는 불가능 하겠지만
마지막으로 취약하다, 차이가 없는 불필요하다는 말은
앞으로 좀더 신중을 기해 주시기 바랍니다.
보안을 하는 기업 입장에서는 보안적으로 문제있다 한마디는
회사에 치명적일 수 있기 때문입니다.
이슈화 된 이후에 업체가 문제 없음을 증명했을때..
"i'm sorry, 몰라서 그랬습니다." 한마디 하시고 끝내실 것이라면요..
문제가 있다, 차이가 없다등의 말씀은
단순한 논리적인 이론과 개념보다는 최소한의 시뮬레이션된 데이터를 제공하는것이 예의 입니다.
그렇지 않으며 이세상의 모든 시스템을 해킹할 수 있다라고 예기하는것과 별반 다르지가 않습니다.
> > > 그냥 인터넷 뱅킹 신청하면 공인인증서 받듯이 받을 수 있을 것 같은데요..- 따온 텍스트 숨기기 -
swlee
2. 악의적인 ActiveX 혹은 ActiveX를 사용해서 보안 통신을 하는 것으로 가장
된 javascript 를 사용자에게 보내줄 경우 (SSL Strip과 비슷한 개념으로)
악의적인 ActiveX 를 어떻게 사용해서 javascript 를 어떻게 사용자에게 보내줄 것입니까??
이런식으로 가정, 가정, 가정한다면 그 무엇도 다 해킹할 수 있습니다.
> > - 따온 텍스트 보기 -- 따온 텍스트 숨기기 -
Jung Tae-young
> 정태영님..
>
> 2. 악의적인 ActiveX 혹은 ActiveX를 사용해서 보안 통신을 하는 것으로 가장
> 된 javascript 를 사용자에게 보내줄 경우 (SSL Strip과 비슷한 개념으로)
>
> 악의적인 ActiveX 를 어떻게 사용해서 javascript 를 어떻게 사용자에게 보내줄 것입니까??
>
> 이런식으로 가정, 가정, 가정한다면 그 무엇도 다 해킹할 수 있습니다.
>
>
SSL Strip 이 하는 게 MITM으로 https 링크를 http로 변경하는 것 입니다. 그
건 가능하다고 인정하시면서 이건 왜 안된다고 하시는건가요. ;)
가로 안의 *SSL Strip과 비슷한 개념으로* 는 괜히 적어 놓은게 아닙니다.
swlee
https 를 http 로 변경하여 평문 데이터를 스니핑 할 수 있는데
ete 암호화는 어자피 스니팅 해 보아야 암호화된 데이터 이기 때문이죠,..
역시 제가 의미하는 application과 의미가 너무 다르니
더이상 토론이 안되겠네요..
Jung Tae-young
> 별반 다르지 않다는 것은 오픈웹만의 생각입니다.
>
> 제가 위에서 링크한 http raw data 를 위변조하는 공격은 소포의 보안 접속이 구현되어 있다면 근본적으로 불가능 합니
> 다.
> 이것은 네트웍 구간에서 암호화만을 보장하는 ssl의 근보적 한계입니다.
> (http://sandsprite.com/Sleuth/stunnel_sslRawreq.html)
기하시는건가요?
http://sandsprite.com/Sleuth/stunnel_sslRawreq.html
이건 공격이 아니라 stunnel을 이용해서 (SSL을 지원하지 않는 통신들까지)
SSL을 이용해서 통신하겠다는 겁니다.
http://muffin.doit.org/docs/rfc/tunneling_ssl.html
위 문서는 http proxy 를 ssl 로 접속할 수 있도록 확장하겠다는 얘기로 보이
구요.
그 외의 링크는 보이지가 않는데, 링크를 잘못 거셨던 건지 아니면 위 링크들
에서 어떤 공격 방법을 찾아내시고 하신 말씀인지 알고 싶네요.
Byung-Jae Jung
보안밥을 먹은지 얼마 안되서 그런지 눈팅만 하려다가 살짝 수면위로 나와봅니다.;;
swlee
알만한 사람은 그정도 내용만 보더라도 어떤 의미이며 어떤 impact 가 있다라는 것을
충분히 알 수 있습니다.
youknowit
알려주신 stunnel 은 해킹공격에 대한 이야기가 아닙니다. http raw data 를 언급하시는데, stunnel 프로그램
이 하는 역할은 평문으로 네트웍에 데이터를 내보내는 POP, IMAP 등의 데몬을 그대로 사용하면서도, 이 데몬들이 네트워크로
보내는 데이터를 암호화하여 안전하게 처리하는 방법을 제공하는 것입니다. 즉, imaps 라든가, secure pop 데몬으로 교
체하지 않고, 기존의 plain text 교신 데몬을 계속 유지하면서도, stunnel 프로그램을 사용하면 정보를 안전하게 처리
할 수 있다는 의미입니다. ("Stunnel can allow you to secure non-SSL aware daemons
and protocols (like POP, IMAP, LDAP, etc) by having Stunnel provide
the encryption, requiring no changes to the daemon's code. )
POP, IMAP 등은 plain tcp 프로토콜로 교시하는데, 이런 플레인 체널로 전달되는 데이터 자체를 SSL 로 암호화 해
서 전달하면 된다는 이야기 입니다. 그래서 "SSL rawrequest"라는 표현이 사용되는 것입니다.
해킹기법에 관한 것도 아니고, https proxy 가 위험성이 있다는 이야기도 아니고, SSL 이 취약하다는 이야기도 아닙니
다.
SSL 프로토콜을 사용하여 기존의 평문 교신 애플리케이션이나, 데몬에게 보안 교신 기능을 부여하는 방법에 불과합니다.
Jung Tae-young
> E2E 는 HTTP 나 HTTPS 와는 전혀 상관업는 Applicaton 레벨에서 암 복호화가 이루어 지기 때문입니다.
>
> https 를 http 로 변경하여 평문 데이터를 스니핑 할 수 있는데
> ete 암호화는 어자피 스니팅 해 보아야 암호화된 데이터 이기 때문이죠,..
>
> 역시 제가 의미하는 application과 의미가 너무 다르니
> 더이상 토론이 안되겠네요..
아침에 보낸 메일에서 얘기했듯이 이 부분은 ActiveX - HTTPS 간의 논쟁과는
상관이 없는 부분이라고 생각합니다. 모든 ActiveX를 걷어내고 HTTPS만 사용
하자고 주장하고 있다면 말씀하시는 부분과 관계가 있겠지만 지금 얘기하는
부분은 *암호화 채널을 ActiveX가 아닌 HTTPS로 구현하자*는 주장이니까요.
공인인증 플러그인을 사용할 경우 내가 보내는 데이터에 대한 서명을 하기 때
문에 (데이터 해쉬 후 이 해쉬값을 공인인증서로 암호화한 값을 데이터에 붙
여서 보냅니다.) 이 값이 변조되지 않았음을 증명할 수 있게 됩니다.
여기 추가로 E2E 보안을 위한 키보드 후킹 방지 플러그인이 사용되고 있는 것
으로 보이지만 요 며칠간의 토론에서 이에 대한 무용성을 얘기하고 있지는 않
습니다.
제가 주장하고 싶은 바는
1. 우선 2차적 장치로 보안 카드와 공인인증서 혹은 OTP가 있으니 공인인증
플러그인을 멀티 플랫폼으로 만들어서 2차적 보안 장치를 만들고...
2. 3차적 보안 장치로써의 키보드 보안, 백신 등의 서비스는 OPTION 으로 만
든다. 혹은 키보드 후킹, 악성 코드 등에 많이 노출되어 있는 윈도우에 한해
서는 키보드 보안, 백신 등의 서비스를 강제하더라도, 상대적으로 이런 문제
에 노출이 되어 있지 않은 맥, 리눅스 등에는 3차적 장치를 강제하지 않는다.
정도 입니다.
Byung-Jae Jung
swlee
평문 http form data 를 조작하여 stunnel을 이용하여 서버와 정상적인 통신을 할 수 있습니다.
서버에 계좌이체로 10000 원을 송신한다면 -10000 으로 조작해서 보낼 수도 있습니다.
즉 ssl 환경만으로는 Application을 공격하는 sql-injection, xss 등의 모든 기법이 간단하게 가능하다는
것입니다.
e2e 보안 접속인 이러한 http 파라메터 조작이 불가능 합니다.
e2e 암복호화를 담당하는 activeX 를 해킹했다는 전제를 해야한 가능한 것이죠..
물론 오픈웹분 말씀대로 이런가정, 저런가정하면 가능 합니다.
> > > - 따온 텍스트 보기 -- 따온 텍스트 숨기기 -
Jung Tae-young
> >> SSL Strip 이 하는 게 MITM으로 https 링크를 http로 변경하는 것 입니다
> 이해가..... mitm과 링크 변경이 무슨 연관성이 있는지..;
> 제작년도 citibank가 SSL MITM로 해킹 당했던 사실들이 왜 openweb에서는
> 무시가 되는지 모르겠네요.
아래 문서의 28 페이지 부터 관련된 내용이 나옵니다.
(제가 잘못 이해한게 아니라면이란 전제가 붙습니다. 틀린 점이 있으면 지적
부탁드리겠습니다.)
- 전제 -
일반 페이지에서 HTTPS 등으로 로그인하게 된다면 실제 링크를 클릭하기 전,
혹은 값이 전송되기 전에는 HTTPS로 값이 전송된다는 점을 증명할 수 있는 점
이 없습니다. - 소스 보기는 논외 -
Internet explorer 등에는 값이 비 암호화 채널을 통해 전송할 때 (EX: 검색
엔진에 검색어 입력) '이 값을 다른 사람이 보게될 수도 있다.'는 경고를 보
여주지만 대부분 '이 경고를 더 이상 표시 안함'를 클릭해놓은 상태로 사용하
지 않던가요.
- 공격 방법 -
하여튼 그런 맹점을 이용해서 MITM 공격을 하면서 HTTPS로의 연결, HTTPS로의
데이터 전송을 HTTPS가 아닌 HTTP로 이루어지도록 바꾸는 것입니다. (html 페
이지를 릴레이 하면서 https로의 링크를 http로 변경)
이 경우 공격자는 고객을 가장하여 서버와 HTTPS 연결을 하게 되고, 공격자와
사용자 사이에는 HTTP(평문 채널)이 형성됩니다. 이를 SSL Strip이라고 부르
며, 사용자가 왠만큼 신경을 쓰지 않는 이상은 문제를 쉽게 알아챌 수 없습니다.
Jung Tae-young
조금 더 부연:
위 슬라이드의 57 페이지를 보시면 아주 간단하게 그림으로 표현되어 있습니다.
또한 사용자가 마치 *HTTPS*로 접속한 것처럼 느낄 수 있도록 favicon 을 변
경하는 치밀함까지 보일 수 있음을 시사해놨네요. (69 페이지)
dasony
swlee님/
SSL Strip은 사용자들이 https://paypal.com 에 접속할때 paypal.com만 입력한다는 헛점을 이용한 것으
로 알고 있습니다. 즉 원래 http://paypal.com에 접속하면 https://paypal.com으로 포워딩시켜서 보안
접속을 사용하게 하지만, MITM 공격자가 포워딩시키지 않고 자신의 http connection을 이용한 웹사이트에 접속하도록
한다는 것입니다. 피싱사이트와 다를 수 있는 것은 사용자의 http 컨넥션 내용을 실제 공격자와 paypal간에 https 컨넥
션 내용으로 서로 포워딩시켜서, 사용자에게는 주소창에 https가 안써있다는 것 외에는 동일한 사이트에 접속한 것으로 안다는 점
입니다. 피싱사이트를 따로 구축하는 비용이 전혀 없기때문이 쉽습니다. 자세한 내용은 이미 올라와있는 부분을 읽어보시면 되겠습니
다.
>해킹에 사용될 수 있지요..
>평문 http form data 를 조작하여 stunnel을 이용하여 서버와 정상적인 통신을 할 수 있습니다.
SSL이 MITM으로 스니핑 할 수 있는 것은 사실인데, stunnel이 어디에 이용되는진 잘 모르겠습니다. 무언가 도움을 받는
데 사용할 수는 있겠습니다.
>e2e 보안 접속인 이러한 http 파라메터 조작이 불가능 합니다.
>e2e 암복호화를 담당하는 activeX 를 해킹했다는 전제를 해야한 가능한 것이죠..
이 전제를 하고 있습니다. 현재의 인터넷뱅킹 환경에서, MITM 공격자가 인터넷 뱅킹 사이트에서 자신의 악성 코드를 설치하도록
코드를 추가하면, 사용자는 현재 뱅킹 사이트에서 제공하는 보안 플러그인이라고 생각하기때문에 설치할 것이라는 이야기입니다. 즉
SSL을 사용할 때 사용자가 주소창과 서버 인증서를 제대로 확인하지 않을 것이기때문에 MITM 공격이 가능하다는 것과 동일한 맥
락입니다. 이 부분은 김교수님이 쓰신 글과 해당 쓰레드를 잘 읽어보시면 아실 수 있습니다.
dasony
덧붙이자면 현재 (상호인증의) SSL방식이나 플러그인 방식이나 중간 네트워크에서만 보자면 동일할겁니다. 굳이 애플리케이션 레벨
의 암호화가 의미가 있으려면, 클라이언트PC의 악성코드가 있다고 했을 때이겠지요.
swlee
dasony
일단 SQL Injection은 정상적인 인터넷 뱅킹 사이트에서 일어나서는 안될 일이고요.
ActiveX로는 막을 수 있으나 SSL의 경우 사용자의 정보가 빠져나갈 수 있는 XSS 공격이 있다면, 그 내용이 궁금합니
다.
swlee
Application 레벨에서 동작하는 해킹 기술에 대한 공감대가 먼저 필요할 것 같네요..
On 4월13일, 오후1시11분, swlee <Bang...@gmail.com> wrote:
> > 의 암호화가 의미가 있으려면, 클라이언트PC의 악성코드가 있다고 했을 때이겠지요.- 따온 텍스트 숨기기 -
youknowit
> 현재의 인터넷뱅킹 환경에서, MITM 공격자가 인터넷 뱅킹 사이트에서 자신의 악성 코드를 설치하도록
> 코드를 추가하면, 사용자는 현재 뱅킹 사이트에서 제공하는 보안 플러그인이라고 생각하기때문에 설치할 것이라는 이야기입니다. 즉
> SSL을 사용할 때 사용자가 주소창과 서버 인증서를 제대로 확인하지 않을 것이기때문에 MITM 공격이 가능하다는 것과 동일한 맥
> 락입니다.
예, 그렇습니다. 다만, 한가지 차이점은 SSL strip 의 경우에는 이용자가 주의 깊게 주소창을 확인하면 감지할 수 있
고, 서버가 client certificate authentication 을 채용하면 아예 불가능한 공격입니다. 제가 제시한
방법("Plugin strip")은 URL 주소 까지 동일합니다. 그리고 서버가 아무리 방비대책을 추가해도 방어할 방법은 없습니
다. 유일한 대책은 이용자가 fake 플러그인 이라는 사실을 오로지 "보안경고창"만을 보고(웹페이지 자체는 완벽하게 은행페이지
와 같지만) 알아내도록 고도로 훈련되어 있어야 한다는 것이지요.
skon
오픈웹에는 swlee님과 같은 분이 절실히 필요했습니다. :)
저도 분위기에 편승해서 질문드려보겠습니다.
1. 윈도우 시스템에서 클라이언트 시스템의 무결성을 믿을 수 없기에 별도의 보안을 담당하는 E2E가 필요함을 얘기하시는 것 같습
니다. 이것은 기존 웹브라우저와 독립적으로 개발될 필요가 있으며 (사실 브라우저가 제공해도 되지만, 개발이나 패치 응답성이 느
릴 수 있겠네요.), 플러그인을 쓰는 것은 좋은 기법일 수 있다.
제가 이해한 부분은 이정도입니다.
그렇다면 Linux나 Mac OS X에서도 이럴 절차가 필요하다고 보시는지요.. 보통 Linux나 Mac OS X는 시스템의 무
결성이 무너졌다는 가정을 좋아하지 않습니다. 그런 일이 벌어졌다고 볼 때, 클린 설치가 해답으로 제시될 정도입니다. 시스템의 무
결성은 시스템 자체의 보안시스템으로 확보하려고 합니다.
그렇다면, 이 경우에도 위에서 말씀하신 E2E가 필요로 하는 것인지요..
2. 논의가 계속 ActiveX를 이용할 경우의 장점과 SSL에서 발생할 수 있는 보안허점으로 연결되고 있는 것 같습니다.
교수님은 SSLstrip이나 SSLsniff 등은 Client Certificate로 막을 수 있지 않겠느냐는 의견을 내셨는데
요..
현재 공인인증은 플러그인으로 한다고 볼 때, 보안접속기술을 SSL로는 Active X에서 제시하는 보안수준을 확보할 수 없을까
요?
(E2E는 역시 플러그인으로 구현한다고 생각하겠습니다.)
dasony
> Application 레벨에서 동작하는 해킹 기술에 대한 공감대가 먼저 필요할 것 같네요..
Application 레벨에서 동작하는 해킹 기술이라는 것은 공격 코드가 사용자 컴퓨터에 설치되었을 경우로 이해해도 될까요? 그
렇다면 플러그인 방식이나 상호인증 SSL 방식이나 위험하긴 마찬가지이겠지요. 물론 플러그인쪽이 공격이 조금 복잡해보이긴 합니
다. 그 대신 현재 ActiveX를 통한 보안 플러그인 배포를 중간에서 가로채면 악성코드 배포도 훨씬 쉬워진다는 점도 있습니
다. (사실 MITM 공격이 실제로 큰 의미가 있다고 생각하진 않습니다. OS 등의 보안 홀을 사용하지, 무슨수로 네트워크를 점
거합니까 ^^; SSL의 허점으로 MITM이 제기되다보니까 MITM이야기가 이만큼 나온 것으로 생각합니다.) 그런데 현재 플러그
인이 사실 애플리케이션 레벨에서 별다른 보안 강화를 하고 있지 않다는 mountie님의 의견도 있었습니다. 역시 이런건 관계자
가 직접 풀어줘야 가능한 이야기일 듯 합니다.
하여튼 슬슬 저도 ActiveX 이야기는 할만큼 한 것 같아서 그만할까 생각 중입니다. ^^; 양쪽다 장단점이 있는데, 결국 표
준이 가지는 크로스플랫폼이라는 장점에 대한 점수를 얼마나 매기느냐에 따라, 최종 결정이 달라지는 것 아닐까 합니다.
swlee님 좋은 이야기 감사드립니다.
Jung Tae-young
> 보안에 대한 지식이 부족한 저희의 질문에 친절하게 답변을 달아주시는 swlee님께 감사드립니다.
> 오픈웹에는 swlee님과 같은 분이 절실히 필요했습니다. :)
>
> 저도 분위기에 편승해서 질문드려보겠습니다.
> 1. 윈도우 시스템에서 클라이언트 시스템의 무결성을 믿을 수 없기에 별도의 보안을 담당하는 E2E가 필요함을 얘기하시는 것 같습
> 니다. 이것은 기존 웹브라우저와 독립적으로 개발될 필요가 있으며 (사실 브라우저가 제공해도 되지만, 개발이나 패치 응답성이 느
> 릴 수 있겠네요.), 플러그인을 쓰는 것은 좋은 기법일 수 있다.
>
> 제가 이해한 부분은 이정도입니다.
>
> 그렇다면 Linux나 Mac OS X에서도 이럴 절차가 필요하다고 보시는지요.. 보통 Linux나 Mac OS X는 시스템의 무
> 결성이 무너졌다는 가정을 좋아하지 않습니다. 그런 일이 벌어졌다고 볼 때, 클린 설치가 해답으로 제시될 정도입니다. 시스템의 무
> 결성은 시스템 자체의 보안시스템으로 확보하려고 합니다.
> 그렇다면, 이 경우에도 위에서 말씀하신 E2E가 필요로 하는 것인지요..
>
육과 관련된 내용이 있었고, 거기에는 다음과 같은 항목이 있었습니다.
5. 안티바이러스
- 바이러스가 자주 감염되는 환경에 대한 Antivirus 설치(WIndows라는 말이
MS로비로 빠졌어요.)
- Antivirus Reporting
저는 키보드 보안, 안티 바이러스에 대해서는 위와 같이 차별적 도입이 필요
하다는 입장입니다.
> 2. 논의가 계속 ActiveX를 이용할 경우의 장점과 SSL에서 발생할 수 있는 보안허점으로 연결되고 있는 것 같습니다.
> 교수님은 SSLstrip이나 SSLsniff 등은 Client Certificate로 막을 수 있지 않겠느냐는 의견을 내셨는데
> 요..
>
> 현재 공인인증은 플러그인으로 한다고 볼 때, 보안접속기술을 SSL로는 Active X에서 제시하는 보안수준을 확보할 수 없을까
> 요?
> (E2E는 역시 플러그인으로 구현한다고 생각하겠습니다.)
>
XecureWeb/INISafeWeb + NProtect + V3 조합을 HTTPS + 공인인증 플러그인 +
NProtect + V3 식으로 바꾸자는 것 아닌가요?
XecureWeb/INISafeWeb에서 *보안 채널*과 *공인 인증*을 동시에 담당하던 것을
보안 채널은 HTTPS, 공인 인증은 XecureWeb(혹은 INISafeWeb) 로 바꾸는 것이죠.
XecureWeb/INISafeWeb의 축소 적용이라고 보는 것이 맞을 것 같습니다. (공인
인증 플러그인이 -최소 국내 표준이라도- 표준화될 경우
XecureWeb/INISafeWeb 등의 솔루션들 중 자기가 원하는 제품 하나를 선택해서
사용하면 되겠죠.)
> On 4월13일, 오전12시11분, swlee <Bang...@gmail.com> wrote:
>
>> 혹시 sql-injection 이나 xss 같은 웹해킹 기술에 대해 알고 계십니까?
>>
>> On 4월13일, 오후12시59분, dasony <das...@gmail.com> wrote:
>>
>>
>>
>>
>>> 위에 글을 쓰다 보니 편집을 잘못했군요. "swlee님/"이 엉뚱한 곳에 들어가있습니다. 죄송합니다 ^^;
>>>
>>> 덧붙이자면 현재 (상호인증의) SSL방식이나 플러그인 방식이나 중간 네트워크에서만 보자면 동일할겁니다. 굳이 애플리케이션 레벨
>>> 의 암호화가 의미가 있으려면, 클라이언트PC의 악성코드가 있다고 했을 때이겠지요.
>>>
> >
>
관련해서는 서버 사이드에서 (고려만 제대로 하고 있다면) 막을 수 있다는 사
실을 더 잘 아실 것 같아 더 말하지 않겠습니다.
dasony
> - 바이러스가 자주 감염되는 환경에 대한 Antivirus 설치(WIndows라는 말이
> MS로비로 빠졌어요.)
> - Antivirus Reporting
>
> 저는 키보드 보안, 안티 바이러스에 대해서는 위와 같이 차별적 도입이 필요
> 하다는 입장입니다.
다 보셨겠지만 혹시 오해하시는 분이 있을까 덧붙입니다. 해당 요구사항은 내부 직원 PC 및 서버에 대한 것이며, 고객 PC에 백
신을 설치하라는 의미는 아니라고 합니다.
Jung Tae-young
> skon 쓴 글:
>
>> 2. 논의가 계속 ActiveX를 이용할 경우의 장점과 SSL에서 발생할 수 있는 보안허점으로 연결되고 있는 것 같습니다.
>> 교수님은 SSLstrip이나 SSLsniff 등은 Client Certificate로 막을 수 있지 않겠느냐는 의견을 내셨는데
>> 요..
>>
>> 현재 공인인증은 플러그인으로 한다고 볼 때, 보안접속기술을 SSL로는 Active X에서 제시하는 보안수준을 확보할 수 없을까
>> 요?
>> (E2E는 역시 플러그인으로 구현한다고 생각하겠습니다.)
>>
>>
>
> XecureWeb/INISafeWeb + NProtect + V3 조합을 HTTPS + 공인인증 플러그인 +
> NProtect + V3 식으로 바꾸자는 것 아닌가요?
>
> XecureWeb/INISafeWeb에서 *보안 채널*과 *공인 인증*을 동시에 담당하던 것을
> 보안 채널은 HTTPS, 공인 인증은 XecureWeb(혹은 INISafeWeb) 로 바꾸는 것이죠.
>
> XecureWeb/INISafeWeb의 축소 적용이라고 보는 것이 맞을 것 같습니다. (공인
> 인증 플러그인이 -최소 국내 표준이라도- 표준화될 경우
> XecureWeb/INISafeWeb 등의 솔루션들 중 자기가 원하는 제품 하나를 선택해서
> 사용하면 되겠죠.)
>
글을 쓰다 말았네요 -_-;; 어쨌거나 하고 싶은 이야기는
앞에서 얘기했다시피 'ActiveX를 통한 암호화나 SSL을 통한 암호화나 거기서
거기고, 범용성을 생각하면 SSL이 더 좋으니 암호화 부분은 SSL로 바꾸자.'
정도 되겠습니다.
윈도우 환경에서는 여전히 나머지를 강제한다고 했을 땐 보안 수준은 똑같겠죠.
다만 비윈도우즈 환경에 대해서는 공인인증 정도까지로 만족하고 나머지는 강
제하지 말아줬음 좋겠다는거...
swlee
다.
따라서 os와는 전혀 별개의 예기입니다.
SSL 은 Secure Socket Layer 의 약자입니다.
즉 네트워크 구간의 암호화만을 보장합니다.
ActiveX 를 이용한 보안 기술은 IE 브라우저레벨에서 동작을 합니다.
애초에 할 수 있는것과 할 수 없는 것이 명확히 다릅니다..
네트워크 레벨의 보안에 대해서만 예기한다면 별반 다르지 않을수도 있지만
서버 Applicaton 보안, 전체 웹보안으로 확장을 한다면 비교대상 자체가 아닙니다.
이말밖에는 드릴 말이 없습니다.
Won-Kyu Park
> Jung Tae-young 쓴 글:
>> skon 쓴 글:
>>
>>> 2. 논의가 계속 ActiveX를 이용할 경우의 장점과 SSL에서 발생할 수 있는 보안허점으로 연결되고 있는 것 같습니다.
>>> 교수님은 SSLstrip이나 SSLsniff 등은 Client Certificate로 막을 수 있지 않겠느냐는 의견을 내셨는데
>>> 요..
>>>
>>> 현재 공인인증은 플러그인으로 한다고 볼 때, 보안접속기술을 SSL로는 Active X에서 제시하는 보안수준을 확보할 수 없을까
>>> 요?
>>> (E2E는 역시 플러그인으로 구현한다고 생각하겠습니다.)
>>>
>>>
>>
>> XecureWeb/INISafeWeb + NProtect + V3 조합을 HTTPS + 공인인증 플러그인 +
>> NProtect + V3 식으로 바꾸자는 것 아닌가요?
>>
>> XecureWeb/INISafeWeb에서 *보안 채널*과 *공인 인증*을 동시에 담당하던 것을
>> 보안 채널은 HTTPS, 공인 인증은 XecureWeb(혹은 INISafeWeb) 로 바꾸는 것이죠.
>>
>> XecureWeb/INISafeWeb의 축소 적용이라고 보는 것이 맞을 것 같습니다. (공인
>> 인증 플러그인이 -최소 국내 표준이라도- 표준화될 경우
>> XecureWeb/INISafeWeb 등의 솔루션들 중 자기가 원하는 제품 하나를 선택해서
>> 사용하면 되겠죠.)
>>
>
> 글을 쓰다 말았네요 -_-;; 어쨌거나 하고 싶은 이야기는
>
> 앞에서 얘기했다시피 'ActiveX를 통한 암호화나 SSL을 통한 암호화나 거기서
> 거기고, 범용성을 생각하면 SSL이 더 좋으니 암호화 부분은 SSL로 바꾸자.'
> 정도 되겠습니다.
이미 언급하신 분이 있었지만,
SSL은 SSL이기때문에 XecureWeb/INISafeWeb + NProtect + V3 를
XecureWeb/INISafeWeb + NProtect + SSL + V3 조합으로 해도
됩니다. 장단점을 모두 흡수하는 형국이 되겠지요.
혹은 SSL(항상 사용) + ( XecureWeb/INISafeWeb or 공인인증플러그인 (activeX 혹은 java
etc. 선택) ) + NProtect 옵션
다음도 함께 참고 링크로 걸어둡니다.
『모질라 firefox와 공인인증서』 http://kldp.org/node/104403 와
전 서명에 관한 표준화 노력
http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0898.html
>
> 윈도우 환경에서는 여전히 나머지를 강제한다고 했을 땐 보안 수준은 똑같겠죠.
>
> 다만 비윈도우즈 환경에 대해서는 공인인증 정도까지로 만족하고 나머지는 강
> 제하지 말아줬음 좋겠다는거...
>
> --
> 오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다.
>
> http://mytears.org/
>
>
> >
>
--
온갖 참된 삶은 만남이다 -- 마르틴 부버
Channy Yun
http://bangjunyoung.blogspot.com/2009/04/blog-post_2428.html
NPAPI로 작성된 플러그인과 그걸 싸고 있는 브라우저에 샌드박스에 의해 보호된다는 말은 오류입니다. 이들이 Firefox에 의
해 download source restiction을 받는다는 것을 잘못 표현했습니다. npplugin 뿐만 아니라 확장 기능
은 설치 시 실제 설치 소스에 대한 허가를 해야만 설치할 수 있게 되어 있습니다. 확장 기능을 설치해 보신 분들은 아실 겁니
다.
따라서 대개 모든 확장 기능은 Addon 공식 사이트를 통해서만 배포되고, 비 정상 사이트에서 배포된 확장 기능은 사용자가 위치
를 허가해 줘야 하고 설사 설치가 되었더라도 업데이트를 하려면 https로 키 인증을 거쳐야만 합니다. 제가 Sandbox라는
말이 헷갈린 점은 이해해 주세요. Mozilla Addon 리뷰 과정을 샌드박스라고 표현을 하기 때문에 그렇습니다.
https://addons.mozilla.org/ko/firefox/pages/sandbox
따라서 Firefox 확장기능(npplugin 포함)이 ActiveX 보다 안전하냐 안하냐는 판단의 문제일 것 같습니다. 저렇
게 이야기하면 Firefox 확장 기능도 잠재적으로 보안에 취약한거거든요. 왜냐면 어떤 종류의 NPAPI 플러그인이 확장기능에
섞여서 배포될지 모르기 때문이죠. 다만 많은 분들이 아직은 Firefox 확장 기능이 ActiveX보다는 보안상 덜 위험 하다
고 느끼는 것 같습니다.
Channy
On 4월13일, 오전12시44분, youknowit <keechang....@googlemail.com> wrote:
> On 4월13일, 오전12시08분, 정 태영 <mas...@mytears.org> wrote:
>
> > 인터넷 익스플로러용 확장기능을 구현하기 위한 방법이 ActiveX(DCOM
> > Component)이고, 모질라 계열 브라우져(+Konqueror)의 확장기능을 구현하기
> > 위한 방법이 NPAPI 인 걸로 알고 있습니다.
>
> > 둘다 내재되어 있는 위험성은 동일하므로 NPAPI로 배포되느냐 혹은 ActiveX
> > 로 배포되느냐로
> > 위험성 여부를 판단할 수는 없을 것 같습니다.
>
> 네, 둘 다가 플러그인 이라는 점에서는 비슷한 위험 요인이 있지만, 윤석찬님께서 지적하신 것 처럼, npPlugin 의 경우 웹
> 브라우저가Sandbox역할을 합니다. 그래서 위험성이 ActiveX 플러그인과 "동일하다"고 하기는 어렵지 않나요?http://groups.google.com/group/open-web/browse_thread/thread/cefbaf8e...
>
> 물론, 제가 적은 것 처럼, npPlugin 형태로만 전자서명 플러그인을 배포, 사용할 경우, MS IE로는 인터넷 뱅킹을 못하
> 게 되는 반면, 파이어폭스, 크롬, 오페라 등 npapi 프러그인을 지원하는 다양한 웹브라우저는 모두 사용이 가능하게 됩니다.
>
> 전국민의 99%에 설치되어 있는 MS IE 를 뱅킹에 사용하지 못하게 한다는 것이 말이되냐? 라고 반문하실 것입니다. 그러나,
> 100%의 국민이 파이폭스나 크롬 등을 설치할 수는 있습니다. 그 설치가 과연 현재 은행들이 설치를 강요하는 ActiveX 플러
> 그인 설치 보다 "비현실적으로 어렵거나 번거로운가"는 논의해 볼 만한 이슈라고 생각합니다. 설치에 필요한 "클릭 수"는 비슷합니
> 다. (은행들이 아예 "파이어폭스 설치 ActiveX"를 배포할 수도 있긴 하지요)
>
> 물론, 지난 10년간 다른 웹브라우저를 못쓰게 막는 것은 당연히 여기면서도, MS IE 를 못쓰게 하는 것은 결코 용납 못하는
> 분들이 대부분일 것입니다. 그분들의 논거는 실은 "보안"이 아닙니다. "뱅킹에서는 보안이야말로 지상의 가치"라고 말씀은 하시지
> 만, 실은 보안이 아니라, 다수의 이용자들이 그저 MS IE 를 사용한다는 "현실"을 더 중요한 가치로 두고, "비록 보안에는
> 상당한 양보를 해야 하지만" 그냥 ActiveX 를 쓰는 것입니다.
>
> "보안이 지상가치이므로 ActiveX 를 써야만 한다"는 반복되는 담론은 적지 않은 "허구"를 담고 있다는 점을 부각시키기 위하
> 여, NPAPI 이야기를 꺼냈습니다. 진정으로 보안이 지상 가치라면, 그리고, 플러그인을 어쩔 수 없이 써야 하는 상황이라면(전
> 자서명은 플러그인 없이 안되니), npPlugin 을 선택하는 것이 논리적으로는 옳지 않겠습니까? ActiveX 보다는
> npPlugin 이 "보안상으로는" 덜 위험하니까...
> 파폭 설치는 2-3분이면 끝나지 않나요?
dasony
는지 모르겠습니다. 그런데 사실 Firefox의 NPAPI가 IE의 ActiveX보다 덜 위험하다고 생각하는건, 맥이나 리눅스
가 윈도보다 안전할 것이라고 생각하는 것이랑 비슷한 맥락이겠죠. (정치적 근거는 있지만 기술적 근거는 없다고 생각합니다.)
그나저나 Form Signing 정도는 XUL/Javascript만를 이용한 extension만으로도 처리할 수 있지 않을까
요? 인증서를 어떻게 관리하느냐가 문제가 되긴하는데, 브라우저의 KeyStore를 사용하든지 extension 자체 공간에 저장
을 하든지 하면 될 것 같습니다. (해당 부분은 자세히 보진 않아서 확실히는 모르겠습니다.) 물론 extension도 악의적
인 extension은 사용자의 정보를 빼갈 수는 있지만, 기껏해야 쿠키 등의 브라우저 내부 정보일 뿐, 시스템에는 접근이 불가
능하니까 조금 더 안전한 대안이 될 듯합니다.
Channy Yun
따라서 Mozilla Addon의 Sandbox 리뷰 시스템이 중요한 거고 사용자들은 가급적 비 Addon사이트에서
제공하는 확장 기능은 잘 살펴 보고 받는 게 중요하죠.
form signing도 xul/js로 비슷하게 구현은 할 수 있을 거에요. 그런데 지금 공인 인증 ui 규격에 인증서는
모두 program files 밑에 npki 디렉토리에 저장하도록 하고 있거든요. 만약 한다해도 이런 규격 바꿔야
하고 쉽지는 않을 것 같습니다.
Channy
Changwoo Ryu
죠. 개정이 되지 않았다면 $HOME/NPKI입니다... 진짜 문제는 USB 토큰이나 스
마트카드용 규격이 MS용만 지정되어 있고 나머지는 빈 칸이라서 이상했던 기
억이 있는데 개정되었는지 모르겠습니다. (그냥 똑같이 지정하면 될 것을.)
지금도 전자정부에서 배포하는 소프트포럼의 x86 linux 공인인증서 확장이 진
짜 ~/NPKI/ 아래에 인증서 저장도 하고 UI까지 비슷하게 구현했었는데요. 어
쩔 수 없이 바이너리 플러그인도 포함하고 있습니다. 지금은 안 돌아가네요.
다시 egov.go.kr 들어가서 깔아 보니 파이어폭스가 죽습니다.
2009-04-14 (화), 23:16 -0700, Channy Yun:
--
Changwoo Ryu <ryu.ch...@gmail.com>
Channy Yun
제가 만능 박사도 아닌데 이제 이런 거 하나도 신경 쓰이네요 ㅎㅎ
egov.go.kr은 행안부의 의지도 있고 하니 잘 될 것 같네요.
Channy
> Changwoo Ryu <ryu.chang...@gmail.com>
somebody
은 얘기들이 오가는 군요. 그간의 많은 얘기들을 모조리 자세하게 다 못 보고 오늘 좀 이것저것 보고 말씀드리는 거라서, 이미
끝난 얘기나 무시할 것은 무시한다고 해주시고, 논점 흩뜨릴 것도 좀 같이 무시해 주시면 감사하겠습니다. 물론 잘못 알고 있는
것 지적해 주시는 수고도 해주시면 전 무척 고맙겠습니다만 귀찮으시면 역시 무시를... ^^
ActiveX를 도입하게 된 배경이,
- 국산 알고리즘 지원
- 서명 기능
- 외국 S/W 업체에 대한 보안
이 세 개가 생각나는데요. 브라우저들이 국산 알고리즘을 지원 안 했고, 국가망에서는 반드시 국산 알고리즘을 써야 한다니
까, 대안이 브라우저 기능을 말 그대로 '확장'시켜주는 플러그인 밖에 없었기 때문이였습니다. 본격적으로 인터넷 보안이 도입될
시기에 아마 IE가 시장 장악을 거의 한 상태였던 걸로 기억이 되는데... 그러다보니 보안 업체들이 없는 자원으로
ActiveX부터 만들었을 것 같습니다. 원 개발 소스가 ActiveX 밖에 없었던 것도 이유였는지 뭐 이런 상세한 사항은
전 모르고요.
서명 기능은 브라우저에 없던 거라 당연히 플러그인들로 '확장'해야 되니까 ActiveX. 넷스케이프 플러그인은 나중
에...
우리가 과연 MS를 믿을 수 있는가? 공개 S/W는 더더욱 믿을 수 없다. IE나 넷스케이프에 백도어를 만들어 놓지 않았다
는 보장은 누구도 못 한다. 뭐 이런 논리도... 이 논리가 국정원에서 나온 건지, 보안 업체 마케팅에서 나온 건지는 모르겠
습니다.
그래서 절대 모든 정보가 외국 프로그램으로 흘러가기 전에 플러그인 단에서 (우리가 만든 실행 파일 안에서) 다 암복호화되고 말아
야 한다.
그렇게 쓰다가, IE의 보안 관련 내부 매커니즘들이 공개되고 하면서, 실제로 국산 보안 알고리즘으로 SSL을 쓰려면 CSP
(Cryptography Service Provider) 만 만들면 되었고. 국내 모 업체에서 개발도 했다는 신문 기사도 본
적 있습니다. 근데 시장화는 안 된 모양이고요. 원인은 모릅니다. 사실 CSP만 팔아서 돈도 안 될 것 같고, 결국 MS
에 종속되어, 조그마한 암호 모듈 하나를, 그것도 공짜인 IE에 끼워팔려니, 국내 영세 보안 업체들한테는 말도 안 되는 사업이
아닐까 하는...
이게 지금 오픈웹에서 얘기하는 것처럼 브라우저에서 제공하는 SSL 쓰면 되는데, 굳이 플러그인 단에서 이것까지 다 하자니
할 일이 점점 많아지는 거지요. 인증서 관련 일들, SSL 각 버전들 지원, 기타 잡다한 것들... 그러다보니 넷스케이프나
모질라 지원은 점점 더 뒤로 미뤄지고...
많이 쓰는 브라우저의 플러그인만 개발되면 해결될 일로 보는데요. 웹 표준에 SSL을 꼭 브라우저에서 지원해야 한다거나 하
는 말은 없지 않나요? 플러그인도 http, SSL, 각종 보안 알고리즘 및 프로토콜, PKI 관련 표준 등 국제 표준들 다
지원하고 있는 것 같은데... 국제 표준 지원하면 되지, de facto인 양대 '브라우저'에 뭔가 맞추어 줘야 할지말지는,
업체가 판단해야할 사항인 걸로 생각됩니다. 사실, 일개 상품들인 브라우저들의 지원을 위해 세금이 쓰여지는 게 은근히 못마땅한
느낌도 없지 않아 있습니다. 물론 과도한 독점 상황을 타개한다는 의미는 충분히 있겠습니다. 시장이 못 해결한 거니까 보이는
손이 개입한다고 생각하고...
음, 카더라 수준 정보에 제 검증 안 된 개인 생각 있어서 논점도 흐트리고 논란의 여지가 상당히 많아질 것 같네요. 위험한데
이쯤에서...
ActiveX의 취약성
하나의 실행 파일로 볼 수 있는 ActiveX의 취약성은 백신 프로그램 영역으로 보입니다. 물론 매우 자주 사용하게 된 브
라우저에서 실행되고, 보안이 매우 취약한 인터넷 상에서 비밀정보들이 왔다갔다한다는 게 상당한 취약점이겠지요. 특히,
ActieX는 권한도 막강하니까... 이 문제야 잘 아시다시피 MS에서 계속 보완하는 거고요. 어차피 IE나 파이어폭스에서
실행되는 플러그인들의 보안 매커니즘은 비슷해져갈 것으로 보고요. 원천은 MS의 독점과 인터넷의 보안 취약성이지 ActiveX
혼자 모든 책임을 덮어쓸 문제는 아니지 않나하는 생각을 조심스럽게 합니다. 사람이 하는 일에 구멍은 항상 생기는 거고, 이것저
것 보완하면서 막아가는 수 밖에 없으니까...
근데 보안에서 사실 중요한 것은 비밀정보들의 관리입니다. 비밀번호나 키, 개인 정보들... 특히 PKI에서는 개인키의 관
리가 무엇보다도 중요한데, 조금 전에 NPKI 디렉터리에 있는 개인키 파일을 다른 컴퓨터에 복사하니가 그대로 되데요. 그래
도 OS나 브라우저나 플러그인 차원에서 단순 복사만으로는 안 되게 해야하지 않나? 하는 생각이 들었습니다. MS의
CryptoAPI에서 개인키 불러오려면 뭔가 상당히 복잡했던 것 같던데... 그래서 키보드 보안 프로그램들이 그렇게 유난을 떨
었구나 하는... 보통 일반 사용자들은 윈도즈에 로긴 암호도 안 걸어놓기 때문에 파일 빼오기는 비교적 쉬울 수 있고 결국 인증
서 비밀번호만 알면 되는데 그거야... 보안의 핵심이 얼마나 쉽게, 얼마나 빠르게 해킹될 가능성이 있는가인데... 물론 앞
서 다른 글타래에서 eric님이 말씀하신 것 처럼 완전하지는 않은거니까요. 아무튼 취약한 것 같네요. 얼마나 취약하냐 하는
건 판단 기준과 상황이 모두들 다르기 때문에...
어차피 모든 보안 기술들이 알고리즘은 다 똑같고 (표준이고) 비밀정보만 안전하게 보관하는 걸텐데요. 프로토콜이나 매커니즘
은 순서나 절차도 중요하지만 결국은 보안 알고리즘으로 다 하는 거니까요. 키 파일 복사로 바로 되는 게 조금 충격이였지만, 컴
퓨터에서 복사만 해서 하느냐 복사해서 조금 뭘 더 해서 하느냐는 차이는 그렇게 크지 않다고 볼 수도 있겠습니다. 해커를 귀찮
게 하는게 최상의 보안일 수도 있겠습니다만, 돈이나 국가 기밀이 걸린 문제에서는 푸는데 1초라도 더 걸리게 하는 게 조금 더 나
을텐데... 작은 시장과 영세한 업계, 열악한 S/W 풍토가 그렇게 유도하는 거겠지요...?
SSL의 MITM
이건 궁금한 건데, SSL 본지도 꽤 오래돼서 그런데, 서버 인증을 할 때 nonny 하나를 암호화해서 클라이언트에 보내주
지 않나요? SSL의 MITM 예로 링크된 페이지들에서는 서버 인증서만 달랑 보내준 후 클라이언트가 인증한다라고 되어 있던
데... SSL에서의 인증 절차들을 많이 생략했기 때문에 SSL/TLS가 취약하다는 인식이 많아지고 있는 건 아닌가 하는 느낌
이 들어서요. 난수 값 하나 풀면서 서버 인증서를 확인하는 과정에서 서버가 정당한 CA로부터 인증 받은 건지 확인하는 절차도
중요한데, 너무 생략한 것 아닌가 하는... 물론 '신뢰할 수 있는 루트 CA나 인증서'로 중간 공격자가 심은 인증서가 이미
등록되어 있다면 무장 해제될 수도 있지만, 그런저런 절차들이 그렇게 간단하게 풀릴 수 있는 보안 매커니즘일까는 조금 의문이 들어
서요.
SSL의 보안성을 취약하다고 하면 대안도 없고, 인터넷을 쓰지 못하는 게 아닌가 하는 생각이에요. 물론 이중삼중으로 이것저
것 보안 장치를 부가해서 쓸 수도 있겠지만 보안과 항상 배치되는 사용성 측면에서는...
쓰다보니 잘못 시작했다는 느낌이 팍팍듭니다. 괜히 다 아는 얘기 또 한 것 같고... 불명확한 얘기들로 논란의 여지만
더 만드는 것 같고...
아무튼 토론은 많으면 많을수록 좋고, 다양한 분들의 다양한 얘기들이 많이 오가면 좋잖아요? ^^ 덕분에 이것저것 알게되는 것
도 많네요. 난잡한 글에 대한 많은 무시와 충고를 기대해 봅니다. ^^