전자서명과 보안접속은 무관합니다.

2009.03.31 글쓴이 youknowit

전자서명과 보안을 마구 혼동하여, 국내 보안업체와 금감원 공무원께서는 “전자서명=보안” 이라는 오해를 거듭 반복하고 있는 듯 하여, 간단히 제가 아는 바를 적어 봅니다.

클라이언트 인증서(뱅킹 고객들이 발급받은 ‘공인인증서’는 모두 클라이언트 인증서입니다)로 이루어지는 전자서명(더 엄밀하게는, 인증서와 쌍을 이루는 개인키로 생성시킨 전자서명)은 신원확인 기능과 거래내역 부인방지 기능을 제공합니다.

신원확인

온라인 상에서의 신원확인(authentication) 기법은 무수히 다양하나, 모두가 공통점이 있습니다. 즉, 오프라인 방식(대면확인)으로 어떤 자의 신원을 먼저 확인하고, 그 자만이 접근, 운용할 수 있는 어떤 수단(비밀번호, 개인키, 생체정보, 보안카드 번호 등 무수히 다양한 수단이 가능합니다)을 직접 건네 주거나, 안전한 방법으로 건네 줍니다. 이것을 확보한 당사자(subject)가 상대방과 거래할 때, 상대방은 그 당사자만이 접근, 운용할 수 있는 수단을 제시해 보도록 요구(challenge) 합니다. 당사자가 이 요구에 응해서 만족스러운 답신 시그널을 보내오면, 온라인 상에서의 신원확인이 이루어진 것으로 보는 것입니다.

예를 들어, 인증서 발급 단계에서는 반드시 대면확인(오프라인 방식) 단계가 있습니다. 은행이 보안카드를 교부할 때도 반드시 오프라인 방식으로 (직접) 교부합니다. 인증서 발급 신청 단계에서도 “인가코드”라는 것을 비전자적 방식으로 직접 교부합니다. 요컨데, 온라인 상에서의 신원확인은 반드시 오프라인에서의 신원확인 단계가 개입되어야 하고, 양 당사자 들이 공유하는 비밀(shared secret)이 이단계에서 전달되어야 합니다. 이것이 일단 이루어지고 나면, 신원확인에 필요한 나머지 단계는 모두 온라인으로 진행될 수 있습니다.

부인방지

거래 내역을 나중에 일방이 부인하면, 분쟁이 발생합니다. 이때, 양 당사자의 주장 중, 누구의 주장을 믿을 것인가를 판단하는데 도움이 되는 자료가 바로 전자서명입니다. 거래 내역(예를 들어, “나는 당신에게 100원을 지급하겠습니다”라는 내용을 담은 전자문서)을 전자서명하여 생성시킨 값(서명값)은 거래의 일방(고객)만이 가지고 있는 비밀 값(개인키)가 없이는 만들어 낼 수 없습니다. 고객과 거래한 웹서버(은행)는 고객이 수행한 거래 내역과, 고객이 그 내역을 전자서명하여 생성시킨 서명값을 모두 보관합니다. 나중에 분쟁이 생길때, 이 데이터를 제시하면, 그 거래 내역이 과연 고객만이 가지는 비밀값으로 전자서명된 것인지를 검증하는 과정을 다시한번 재연할 수 있으므로, 거래 내역을 부인하는 고객의 주장이 설득력이 없게 되는 것입니다.

보안 접속

교신의 보안은 이러한 정보들(거래 내역, 전자서명값 등), 또는 그 외의 어떤 정보건 간에, 해당 정보가 네트워크 상에 오고가는 동안 제3자가 가로채더라도, 그 내용을 읽어볼 수 없도록 하는 기능을 수행합니다.

보안 접속을 한다고 해서 거래 내역의 서명(form-signing)이 이루어지는 것도 아니고, 거래 내역을 전자서명한다고 해서 보안접속이 이루어지는 것도 아닙니다. 보안 접속은 “클라이언트의 신원확인(authentication)” 기능도 물론 없습니다(SSL 서버인증서를 사용한 보안접속의 경우, 서버의 신원을 확인하는 기능은 있습니다). 클라이언트의 신원확인은 비밀번호라든가, 보안카드 번호라든가, 전자서명 등의 수단으로 이루지는 것이지, 보안접속이 클라이언트 신원확인 기능을 제공하는 것은 아닙니다.(보안접속 세션은 익명접속 세션 – anonymous SSL session – 도 있고, 접속자 인증 세션 – client authenticated SSL session – 도 있습니다. 신원확인기능은 후자의 경우에만 가능합니다)

구현 방법

현재 보안접속은 웹브라우저에 내장된 HTTPS 접속 기능을 이용하는 것이 가장 간편하고, “국제적으로 검증된” 안전성을 제공합니다. 국내 보안업체들이 90년대 후반에 개발하여 아직까지 사용하는 보안접속 플러그인 더 안전하냐, SSL/TLS 프로토콜을 이용한 https 보안접속 방식이 더 안전하냐를 두고 지난 여러해 동안 국내에서 논란이 있었지만, 이 문제는 애초에 논란거리 자체가 안 되는 사안이었습니다. 국내의 업체들이 사용하는 별도의 플러그인도 결국에는 SSL 접속을 합니다. 즉, 웹브라우저가 당연히 할 수 있는 SSL 보안접속을 하기 위하여 국내 은행들은 별도의 플러그인을 사용하는 것입니다. 자세한 설명은 여기.

다만, 현재 국내에서만 사용되는 “별도 플러그인 방식의 보안접속”과 전세계적으로 사용되는 “https 보안접속” 간에는 다음과 같은 차이가 있습니다.

한국에서만 사용되는 국내 업체들의 구현 방법에 대하여는 전세계의 보안전문가가 객관적으로 검토, 검증할 아무런 자료(documentation) 도 없습니다. 해당 업체와 그 기술의 prototype을 개발하였던 ETRI 의 기술진이 안전하다고 하니, 그냥 믿으라는 것이지요. 반면에 https 보안접속의 상세한 기술 명세는전세계적으로 투명하게 검증 가능한 수준으로 상세히 존재합니다.

국내 기술인력의 수준을 폄하하는 것은 결코 아닙니다. 외국의 어느 업체나, 연구소가 개발한 보안접속 구현방법이라 할지라도, 그 구현기법에 대한 상세한 documentation 이 없는 상태라면, 그 기술이 과연 안전한지, 위험한지는 세계 어느 누구도 자신있게 말하지 못할 따름입니다. 국내 보안업체들이 지난 10년간 사용해온 보안접속 구현기법이 “영원히 국내용”으로 남을 수 밖에 없는 이유는, 그 안전성을 객관적으로 검증할 자료가 전혀 제공되지 않기 때문에 어느 누구도 자신있게 그것을 채용할 엄두를 감히 못내기 때문입니다(우리야 뭐, 서로 믿으니까… 그냥 일단 저지르고 보는 것이지만)

현재, 접속 고객의 신원확인(authentication)에 필요한 수준의 전자서명 기능(인증서 로그인 기능)은 주요 웹브라우저에 이미 탑재되어 있습니다. 즉, 인증서 로그인을 위해서라면, 별도의 플러그인이 필요없습니다. 그러나, 거래의 내역을 고객이 전자서명하는 기능(부인방지 기능)은 별도의 플러그인으로 구현할 수 밖에 없습니다. 이 플러그인은 ActiveX 형태로 웹브라우저와 연동시킬 수도 있고, 파이어폭스 확장 또는 서명된 자바 애플렛으로도 구현 가능합니다.

이메일을 전자서명하는 기능은 몇몇 이메일 프로그램이 이미 탑재하고 있거나, 부가 프로그램 형태로 존재합니다.

http://openweb.or.kr/?page_id=54#comment-23954 도 일별하시기 바랍니다.

국내 보안업계 종사자분들 중에는 물론 오픈웹에 대하여 비판적 입장을 견지하는 분들도 많습니다. 그런 분들께서도 보다 적극적으로 오픈웹의 논의에 참여해 주시면 우리 모두에게 도움이 될 것입니다.

  • http://snowall.tistory.com snowall

    인터넷 연결 없이 설치하셔도 됩니다. 단, 전체 설치 CD를 갖고 있어야 겠죠. 부팅만 되는 복구용 디스크 등으로는 안됩니다.
    무선랜카드가 최근에 나온 것이고, 우분투를 최신 버전으로 사용하신다면 그냥 아무 생각없이 시도하셔도 자동으로 잘 될 겁니다. 나머지는 KLDP 등 리눅스 커뮤니티에 질문하시거나 인터넷 검색을 참고하시는게 도움이 될 것 같습니다.

  • 손님

    우분투 한국 사용자 모임에서 많은 분들이 도와 주실 겁니다.
    http://www.ubuntu.or.kr/

  • http://www.gilgil.co.kr 이경문

    저는 보안 관련 회사를 다녀 본 적도 없고 지금도 다니는 상태는 아니지만 평소 보안예 관심을 많이 가지고 있고, 관련 업계의 많은 분들을 알고 지냅니다. 직접 글을 달지는 않지만 보안 업계에 종사하시는 많은 분들이 본 사이트를 주의깊게 살펴 보고 있다는 점을 알아 두시기 바랍니다.

    보안 종사자들 중에 본 사이트에 덧글을 달고자 했던 분들이 한둘이 아닐 것이지만, 보안업계의 입장에서 댓글을 달았을 경우 마치 정부를 옹호하는 것처럼 보일 수 있다는 것이 글을 달 수 없도록 하고 있는 상태입니다.

    ActiveX로 만연되어 있는 현 국내 사이트의 문제점을 지양하고, 표준을 따라야 한다는 것은 그 어느 누구보다도 보안업계의 사람들이 잘 알고 있습니다.

    오픈웹 초기의 위상과는 달리 지금은 “누구는 빅브라더구나” 라는 식으로 마녀사냥으로 나간다면 그 어느 누구도 교수님의 주장에 토론을 같이 하고 동조를 할 수 없을 것입니다(현재 오픈웹의 주장은 너무 극단적입니다).

    바라건데 “누구의 잘못인가?”를 논하기 보다가는 “어떻게 할 것인가? 고민할 수 있는 사이트가 되기를 기원합니다.

  • http://snowall.tistory.com snowall

    이경문/ 저는 앞으로의 방향을 고민해야 한다는 점에는 동의합니다. 하지만 보안업계 분들이 정부를 옹호하는 것처럼 보일 수 있는 것을 겁내서 댓글을 달고 있지 못한다는 점은 아쉬운 점입니다.
    제 생각에는, 정부의 입장이든 보안업계의 입장이든 각자의 입장에서 스스로를 옹호하는 것은 그다지 문제가 되지 않을 것이라 생각합니다. 완전한 억지 주장만 아니라면 말이죠.
    오히려, 지금 오픈웹의 모습이 극단적으로 비춰지는 것은 그런 보안업계 분들의 댓글이 없어서 댓글이 한쪽으로 쏠리는 것일 수도 있습니다.
    앞으로 어떻게 할 것인가를 고민하는데 있어, 보안 업계 전문가 분들의 의견도 많이 들을 수 있으면 좋겠습니다.

  • http://openweb.or.kr youknowit

    지난 9년간 계속되어 왔고, 지금 현재 계속되는 사태보다 “더 극단적”인 상황은 제 능력으로는 상상하기 어렵습니다.

    마치 “어느 정도” 균형이 잡혀있는 현 상황에서 오픈웹이 극단적 주장을 펴는 것처럼 말씀하신다면, 동의하기 어렵군요.

    오픈웹의 목적은 과거를 시비하자는 것이 아닙니다. 지금 당장 바꾸자는 것입니다. “현재”가 문제입니다.

    틀린 것을 틀렸다고 분명히 말하지 않고서야 어떻게 변화가 가능하겠습니까?

    보안 업체 분들이 그동안 자신들이 옳았고, 지금도 옳다는 주장을 펴고 있고, 저는 그런 주장이 전혀 근거가 없는 거짓말이고 생각합니다.

    어쩡쩡한 양비론, 양시론으로 적당히 엉거주춤한 입장을 펴는 것은 사태 자체가 어느 정도 중립적일 경우에야, 온건하다는 평가를 받을 수 있겠으나, 한국 인터넷 뱅킹을 대상으로 그런 입장을 유지하는 것은 무책임하거나, 자신의 이해관계 때문에 애써 동문서답을 하고 있는 것에 불과하다고 저는 생각합니다.

  • AppleADay

    한국에서 영어를 가르치고 있는 Expat이 쓴 글입니다. 참조하세요.

    Everything That’s Wrong with the Korean Internet
    http://stafford.squarespace.com/imported-data/

    마지막 문장이 우리가 모두 하고 싶은 말입니다.
    “Die Active – X Die!”

  • http://www.gilgil.co.kr 이경문

    여기에 글을 다는 것이 자칫 “보안업계”를 대변하는 것 같고, 오픈웹의 취지(표준을 지키자)를 반박하는 듯하여 댓글 달기가 사실 겁이 납니다. ㅎㅎ 보안업계에 계신 분들과 좀더 의사소통의 기회가 주어진다면 좋을 것 같군요
    아울러 대한 저의 개인적인 의견을 쓰 봤습니다.

    만연되어 있는 ActiveX 누구의 잘못인가?
    http://www.gilgil.co.kr/bbs/zboard.php?id=free&no=2787

    SSL에 대하여
    http://www.gilgil.co.kr/bbs/zboard.php?id=free&no=2788

  • T. K.

    교수님 비롯해서 여기 오시는 분들 그렇게 꽉막힌 분들 아닙니다.
    저도 결코 ‘완벽한’ 보안 솔루션은 존재하지 않는다고 생각합니다. 이런 논의는 활발할수록 좋습니다. 실현가능한 대안을 찾아 바꿔나가자는 것이니까요.

    다만 보안업 종사자분들이라도 ‘알지도 못하면서 남의 밥그릇 쑤시지나 마라’ 이런 식으로 비난하신다면 조용히 가운데손가락 하나 올려드리겠습니다.

  • http://www.gilgil.co.kr 이경문

    국내 웹 환경이 다양한 플랫폼에서 돌아 가야 한다는 오픈웹의 취지에는 100% 환영을 합니다. 하지만, 보안업계에 몸을 담고 있는 사람들이 국내 ActiveX가 만연되어 있는 웹 환경을 만들어 버린 원흉이라는 전제하에서는 보안업계와 오픈웹 사이에서 어떠한 논의나 동의조차도 이루어 질 수가 없습니다. 민감한 시점에서는 서로에게 건네는 말 한마디 한마디가 중요하다고 보여 집니다. “가운데 손가락” 같은 얘기는 삼가해 주셨으면 하네요. ^^

  • T. K.

    네. ^^

  • http://channy.creation.net Channy

    @이경문, 모든 보안 기술이 그렇듯 SSL 역시 완벽하지는 않습니다. 위의 쓰신 글의 SSL Spoofing의 거의 대부분이 악성코드에 의한 1차 감염에 의한 것도 있고 피싱 처럼 사용자가 무지해서 당하는 것도 있습니다.

    두 가지 모두 OS나 브라우저가 해결하려고 계속 노력 중이죠. 예를 들어 EV Cert와 브라우저에 인증서 보안강도별 색상 표시 같은게 그런건데요. 사용자들이 OS나 브라우저를 업그레이드하면서 해결 가능한 것들이죠.

    그런데 우리 나라는 이러한 OS나 브라우저 업그레이드가 어려운 상태입니다. ie8깔지말라고하고 uac꺼라고 하고 보안경고창엔 무조건 예하라고 하는게 보안업체가 컨설팅하고 있는 천만 공인인증서 시대의 우리나라의 자화상입니다.

    현재 플러그인 방식만 가지고 예를 들자면, 웹 서버 보낼때는 서명해서 데이터 암호화해서 메시지 보내는데 받을때는 그냥 80포트니까 계좌 내역도 평문으로 날라왔었습니다. 아직 그런 은행이 있을지도 모르는데요.

    어쨌든 어느 것도 완벽할 수는 없습니다. 하지만 적어도 웹브라우저나 OS도 업그레이드 못하게 막는 시스템은 보안에 좋다고 볼 수는 없어요.

  • mountie

    이경문님 SSL 공격에 대한 글을 읽고 의견드립니다.

    DNS 체계가 허물어진것을 가정(*)하고 나머지 과정을 설명한것으로 이해됩니다.
    이 경우 해커입장에서는 어려운 SSL middle attack뿐만 아니라 피싱, HTTP packet capture등 다른 쉬운 방법도 다 동원할 수 있다고 생각합니다.
    SSL이 그나마 서버접근시 인증서 오류 경고를 보여주지요.
    DNS Server가 공격자 통제하에 들어가면 어떤 통신방법을 쓰든지 그 DNS 서버를 이용하는 Machine전체가 위험한것은 마찬가지고
    개별 PC의 DNS 체계가 공격자 통제하에 들어가면 Key-Logging 등 훨씬 다양한 정보입수 방법이 생기지요.

    SSL이 완벽한 보안을 제공하는것은 물론 아니지만 그나마 가장 훌륭한 대안이라고 생각합니다.

    수천만개 발급된 공인인증서로 SSL Client 인증을 활성화하는것도 하나의 방법이 될 수 있지요.

  • http://openweb.or.kr youknowit

    이경문님께,

    논의에 참여해 주셔서 진심으로 감사드립니다. 오픈웹이 말그대로 “오픈”되어 있고, 누구라도 편안한 마음으로 와서 논의할 수 있는 곳으로 남아있기를 저는 간절히 희망합니다.

    Channy 님께서 이미 말씀하셨듯이, SSL 방식이 100% 안전한 것도 아니고(컴퓨터 보안에서 “100%”라는 말 자체가 무의미 합니다; 100%라는 말은 아예 거론해서는 안될 용어라고 저는 생각합니다), 플러그인 방식의 국내 해법이 “위험하다”는 단정적인 주장은 적어도 오픈웹의 입장은 아닙니다.

    그러나, 양자 간에는 중요한 차이점이 있습니다.

    첫째, SSL 은 모든 플랫폼을 지원합니다.

    둘째, SSL 은 그 설계의 자세한 내용에 대한 완벽한 documentation 이 있으므로, 전세계의 전문가들이 그 안전성을 객관적으로 평가, 검증할 수 있고, 해왔습니다.

    셋째, SSL 방식을 채택하면, 온 국민에게 “보안경고창이 나타나면 반드시 예하라”는 해괴망측한 지시를 할 필요가 없습니다. 오픈웹이 “위험하다”고 단정적으로 말하는 부분은 바로 이”지시”이고, 이런 지시와 “세뇌”로 형성된 이용자의 이용행태가 위험하다는 것입니다.

    다섯째, SSL 방식은, 서비스 제공자 입장에서 메인터넌스, 고객지원 비용이 제로에 가깝습니다. 국내 은행들의 IT 지원부 인력의 대부분은 고객의 전화받기에 바쁩니다. 그 내용은 전부 “액티브 액스 설치가 않되요…ㅠㅠㅠ”

    여섯째, SSL 방식은 컴맹도 아무 어려움 없이 서비스를 이용할 수 있습니다. 컴퓨터를 모르는 어르신을 위해서 액티브 액스 방식을 채용했다는 말은 옛날 예적의 “흘러간 추억의 가요” 수준의 말입니다. 액티브 액스 설치는 이제는 매우 어렵고, 복잡하고, 여러번의 이용자 개입(user intervention)이 필요한 방법으로 되었습니다.

    일곱째, SSL 방식을 채용하면, 솔루션 제공자 입장에서도 별도의 업그레이드/리컴파일 등이 필요없습니다. 액티브액스로 솔루션을 제공하고 나면, 끊임없이 플러그인 업그레이드를 해줘야 합니다.

    여덟째, 한국식(프러그인 방식)으로 보안접속을 할 경우, shared key 를 공유 상태를 유지하기 위하여 웹사이트 전체에 프레임을 사용하지 않을 수 없습니다. 이럴 경우 여러가지 문제점이 한꺼번에 따라옵니다.

    저는, 액티브 액스 방식이 누구를 위해 편하고, 좋다는 것인지 이해할 수 없네요.

  • mountie

    회사 일로 일본 인터넷 뱅킹을 여러개 이용하고 있는데
    국내 환경과 비교하여 다른 몇가지를 살펴보면 아래와 같습니다.

    1. 대부분 SSL Client 인증을 활성화하여두고 있습니다.
    - 제가 사용하는 Client 인증서는 PKCS#11 표준 보안 USB에 담겨 있습니다.(Safenet iKey)
    - PKCS#11 표준을 지원하는 다양한 OS 및 브라우저에서 사용가능합니다.

    2. 철저한 세션 통제
    - 세션 관리가 아주 철저하여 브라우저 back 버튼도 막아두고 꼭 안내하는 링크를 클릭하여 각 메뉴로 접근하도록 하고 있습니다.

    3. 비밀번호 및 Account Lockout 정책
    - 엄격한 비밀번호 및 어카운트 Lockout 정책이 적용되고 있습니다.
    - 비밀번호 복잡성, 비밀번호 재사용금지 등등
    - 반복된 잘못된 시도등에 대해 account가 자동 lock되고 manual process로 풀어줍니다.

    4. 부인방지를 위한 2차 비밀번호 이용
    - 서면 인터넷뱅킹 신청시 계약사항에 2차 비밀번호에 대한 부인방지 효과에 대한 사용자 동의를 받습니다.
    - 이후 모든 중요한 인터넷 뱅킹 행위(이체 등)에 대해서는 2차 비밀번호를 한번 더 입력하게 합니다.

    ———-
    이런 구조하에 우리돈으로 몇억원을 문제없이 이체하고 있습니다.

    • mountie

      한가지 추가하면
      일본 인터넷 뱅킹 은행에서 보안 USB를 어떻게 사용하라고 안내하지는 않습니다.
      브라우저에서 지원하는 범위내에서 알아서 보안 USB를 사용하는것이고
      은행에서는 유저가 보안 USB를 사용하는지 여부를 구분할 수는 없습니다.

  • http://www.gilgil.co.kr 이경문

    mountie님 / “SSL이 완벽한 보안을 제공하는것은 물론 아니지만 그나마 가장 훌륭한 대안이라고 생각합니다.” 이 말씀에 저도 동의를 하는 바입니다. 현재 보안통신에 있어서 가장 효과적인 방안이 바로 SSL입니다. 다만 “뭐든지 100% 안전하다고 믿지는 말자”라는게 저의 의견이구요. ^^

    기술적으로 말씀을 드리자면 제 사이트에서 예시한 링크는 전부 DNS spoofing과는 전부 무관한 기법들입니다. 특히 올해 초에 발표된 sslstip이라고 하는 것은 “인증경고창”도 안뜨고 DNS 변경같은 액션도 전혀 취하지 않습니다. 일반사용자뿐만 아니라 전문가들도 쉽게 알아 차릴 수 없는 공격 기법입니다. 알 만한 사람들은 이미 다 알고 있던 것이었고 언젠가는 공개가 되겠지 예상만 했었는데 결국에는 이렇게 수면 위로 이슈화가 된 것이구요.

    사실 본 사이트에 제가 이런 얘기를 하는 것이 어려운 이유가, 제가 이렇게 “SSL도 100% 안전하지 않다” 라고 얘기를 하게 되면 “그럼 오픈웹의 본연의 취지를 무시하려 하느냐?”라는 뉘앙스로 들릴까봐 하는 걱정에서입니다.

    제가 말씀드리는 것은 본 사이트에서 얘기되어 지는 많은 얘기들중에서 기술적으로 보완을 해야 할 부분들이 간혹 보인다는 겁니다(개발자의 입장에서 볼 수 있는 것은 개발과 관련된 사항들뿐이니까요)

  • 맥매니아

    교수님… 한국에서 이제 i-pin 제도를 도입한다고 하는데요. Active X를 사용합니다. 저는 맥사용자로서 i-pin 제도 자체가 맘에 들지 않습니다. (실명제문제포함해서) 이문제에 관한 교수님의 의견은 어떠하신지요?

  • youknowit

    대한변협신문 2009.3.16. 자 기고문이 혹시 참고가 되시려나 모르겠네요.

  • mountie

    sslstrip을 잠시 살펴봤습니다.
    SSL Certificate chainning 구조하에서 validation을 통과하는 가짜 SSL Certificate를 생성하는 것에 대해서는 이해가 됩니다.
    이게 가능한 환경을 생각해보면
    ARP Spoofing이든 DNS Spoofing이든 유저 request를 공격자가 준비한 뭔가가 가로채야하고
    공격자가 어딘가 들어와서 뭔가를 심어놔야지 가능하겠군요. 유저PC든 다른 어떤 서버든.
    ——–
    막는 방법은
    - 브라우저 패치(나와있는지는 미확인)
    - SSL Client 인증 (이 방식은 확실히 막을 수 있음)
    - 서버측 인증 프로세스 개선 (Secure Cookie 활성화, 패스워드 입력을 SSL 세션하에서 진행하도록 하고 Secure Cookie 활성화하여 사전에 현재 유저가 SSL Connection하에 있는지 확인? 등)

    등을 생각해볼 수 있고

    즉 이러한 공격 가능성에 대해서도 우리가 일반적으로 알고 있는 범용 표준기술로 대응방안을 마련해볼 수 있다는 것을 이야기하고싶군요 (궂이 ActiveX등을 사용하지 않더라도)

  • http://www.gilgil.co.kr 이경문

    같은 생각의 다른 표현이라고 할까요? 글이 길어 져서 다시 저의 개인 홈피에 글을 적어 봅니다. 다시 한번 말씀드리지만 보안 업체를 비판하는 것만으로는 절대 해결책이 될 수가 없음을 말씀드립니다.

    http://www.gilgil.co.kr/bbs/zboard.php?id=free&no=2789

  • http://www.gilgil.co.kr 이경문

    mountie 님 / ARP spoofing 이나 DNS spoofing은 Attaicker가 양 통신 주체의 중간에 위치하도록 하는 기법(MITM)으로 이런 본 논의에서는 배제를 하구요,

    sslstrip : “https://” 문구를 “http://”로 바꾸는 겁니다. 기술적으로는 굉장히 쉬운 거죠. 다만 중간에서 이를 위해 plain http 통신와 ssl http 통신을 중간에서 처리해 주는 proxy가 존재해야 합니다.

    rogue certificate은 MD5 가능성 원리를 이용하여 노가다 삽질을 통해서 가짜 CA 인증서를 만들어 내는 겁니다. 기술적으로는 여기에 더 점수를 주고 싶습니다.

    개인적은 생각으로 rogue certifiacate 취약점은 hashing 알고리즘을 달리하여 인증서를 재배포하면 금방 해결되는 것인데, sslstip은 당분간 문제가 계속 될 것입니다. 보통 사용자가 웹주소를 입력할 때 “https://”를 직접 입력하는 사람은 별로 없죠? 웹통신의 기본이 80(plain http)번에서 443번(ssl http)로 바꾸지 않는 한은 계속 존재할 수 밖에 없는 취약점으로 보입니다.

  • http://www.gilgil.co.kr 이경문

    에고, 오타가 많네요, 댓글 수정이 안되네요. ㅎㅎ
    Attaicker > Attacker
    MD5 가능성 원리 > MD5 충돌 가능성 원리
    certifiacate > certificate
    sslstip > sslstrip

  • http://www.gilgil.co.kr 이경문

    제가 보안에 대해 가지고 있는 지식은 그냥 주워 들었거나 전문가(white hat)에 의해서 공개된 PoC 문서를 보고 가끔씩 직접 프로그래밍으로 구현해 보는 정도입니다. 오픈웹 사이트에서 기술적인 부분에 대해 언급되는 부분들을 보고 있노라면 맞는 말들이 많지만, 가끔씩 올바르지 않는 것에 대해 확신을 가지고 얘기하는 것들이 보이는 것 같습니다. 제가 보기에도 “이건 아닌데…”라는 생각이 드는데, 하물려 정말로 전문가들이 보면 어떻게 생각할까 라는 우려가 듭니다.

  • 표정현

    글들을 읽다보니 보안과 관련해서 지식을 가지신 분들이 오히려 부정적인 견해를 보이시는군요. 큰 뜻에는 동의하지만 각론에서는 이건 이래서 안되고 저건 저래서 안되고라는 식이네요. 저는 그다지 지식은 없습니다만 뭐가 그리 어려운 일인지 모르겠습니다. 제가 미국이나 일본 아마존에서 수십번 구매를 해보고 아마존 뿐만 아니라 소규모 출판사에서도 직접 카드로 온라인 결제를 하여 책이나 저널을 구입해 본 적도 있지만 추가 프로그램을 전혀 설치하지 않고도 단 한번도 결제와 관련해서 사고가 발생한 적이 없었습니다. 하지만 국내에서 온라인 거래를 한번 할라치면 뭐 그리 설치하라는 것이 많은지. 그나마 설치할 것인지 말 것인지를 선택할 권한도 주어지지 않습니다. 아마존과 같은 카드 결제 시스템을 만드는 것이 어려운 일인가요? 하다못해 꼭 필요하지 않다고 제가 판단한 프로그램에 대해서는 “아니오”를 선택할 권리라도 돌려 줬으면 좋겠습니다.

  • http://www.gilgil.co.kr 이경문

    youknowit님 / 법쪽으로는 제가 문외한이라서 잘 모르겠습니다. 죄송합니다. ^^

    mountie 님 / SSL 취약점에 대한 방안을 말씀하셨는데요, SSL 취약점을 Reverse Engineering(상대방 PC에 백도어 심기)의 분야가 아니라 네트워크 취약점 분야에 국한시켜 얘기해 보겠습니다.

    (1) 브라우저 패치(나와있는지는 미확인) : MITM 공격으로 인해 인증서 바꿔치기를 하면 서버 인증 과정에서 브라우저는 경고창을 띄웁게 됩니다. 그런데 인증서가 틀리다고 해서 100% 차단만을 할 수는 없습니다. 웹브라우저의 버전이 업그레이드될 때마다 그 경고창의 문구가 더욱 위협적으로 표현을 하는 것이 웹브라우저가 할 수 있는 역할의 전부입니다. https://www.sf.net , https://www.sourceforge.net , https://sourceforge.net 3개의 사이트가 전부 똑같은 인증서를 사용하고 있는 예를 봐도 그렇습니다(Common Name이 전부 sourceforge.net 하나로만 되어 있음).

    (2) SSL Client 인증 : 원래 SSL통신 모듈은 클라이언트 인증과 서버 인증 모두를 지원하고 있습니다. 그런데 현재 웹상에서의 SSL 통신은 서버인증 방식만 채택하고 있습니다. 클라이언트 인증까지 하면 보안상으로 더욱 안전할 수 있다라는 것은 당연한 얘기지지만 현실적으로 불가능합니다. 무수히 많은 웹서버에 인증서를 발급하는 것도 특정 업체(root CA기관) 배불려 주는 거다라고 이권 다툼으로 말이 많은데, 서버 갯수보다 수천, 수만배나 많은 모든 웹클라이언트에 인증서를 도입하겠다고 하는 것은 거의 불가능에 가깝습니다. 또한 제가 알고 있는 상식으로 현재 국내 공인인증서가 바로 클라이언트 인증에 사용되는 것으로 알고 있는데(이것때문에 일반인들에게 몇천원을 부가하는 것이죠), 그렇게 되면 결국 지금과 같이 형태의 웹이 지저분해 지는 꼴이 날 수 밖에 없고, 오픈웹에서 주장하는 것과 정 반대의 결과를 초래할 수 있습니다. SSL 웹 통신에서는 이러한 문제때문에 클라이언트 인증을 절차를 과감히 포기한 것이고, 국내 인터넷 뱅킹은 불편하지만 클라이언트 인증까지 포함하고 있는 것입니다. 결국 보안과 편리의 추구는 상반된 개념일 수 밖에 없습니다. 무엇이 정답이냐는 그때 그때 달라 지게 됩니다.

    (3) 서버측 인증 프로세스 개선 : 솔직히 무슨 말인지 잘 모르겠습니다. Secure Cookie 채택으로 MITM Attack을 막을 수 있는지 이해가 되지 않습니다(제가 이쪽으로는 처음 듣는 말이라서 정말로 무슨 말인지 모르겠습니다).

    본 사이트에서 기술적인 내용들에 대해 자세히 언급을 하는 것이 내편/네편 가르기가 아님에도 불구하고 오픈웹의 취지를 반박하는 것 같이 보여서 저 자신도 안타깝습니다. 이는 애시당초부터 현재 한국의 인터넷의 상황의 잘못의 원인이 바로 “보안업계”에 있다라고 주장을 하는 본 사이트의 성격에 기인한다고 봅니다.

    본 사이트에서는 어떠한 얘기를 해도 결국 돌아 오는 것은 좋지 않을 얘기일 것임이 예상되기 때문에, 앞으로는 저의 의견 표출은 자제하도록 하겠습니다.

  • http://openweb.or.kr youknowit

    이경문/
    위에 제가 언급한 대한변협기고문은 i-pin 에 대한 맥매니아님 댓글에 관한 것이었습니다.

    “클라이언트 인증”이라는 말은 조금 오해하신 듯 한데, 클라이언트 컴퓨터에 마치 서버인증서와 같은 것을 탑재한다는 뜻이 아니고, 고객이 인증서 로그인을 한다는 뜻입니다. 인증서 로그인을 별도 플러그인 방식으로 해야 할 이유는 없습니다. 웹브라우저에 이미 인증서 로그인 기능이 기본 탑재되어 있습니다.

    물론, 지금처럼 괴상한 위치에, 특이한 형식으로 저장된 인증서는 웹브라우저가 읽어들일 수 없습니다. pfx (pkcs12) 양식으로 변환해야 웹브라우저를 통한 인증서 로그인이 가능합니다. 이를 위해서는 공인인증서 저장양식이 바뀌어야 하겠지요.물론 지금도 공인인증서 내보내기/불러오기 기능은 있지만, 이것을 실제로 알고, 수행할 수 있는 이용자는 1%도 안된다고 봐야 겠지요.

  • http://www.gilgil.co.kr 이경문

    youknowit 님 / 음… PKCS라는 것이 있었군요. 몰랐었습니다(사실 제가 보안을 정식으로 공부한 적이 없고, 전부 야메로(술자리)에서 어깨 넘어 배운 것이라 기초가 부족합니다) 좋은 정보 감사합니다. 시간 날때 한번 검토해 보도록 하겠습니다. 그나 저나 여기 저기 글 올리고 읽고 하느다 다들 잠은 제대로 주무셨나 모르겠네요. ㅎㅎ

  • 몽몽이

    [국내 보안업체들이 지난 10년간 사용해온 보안접속 구현기법이 “영원히 국내용”으로 남을 수 밖에 없는 이유는, 그 안전성을 객관적으로 검증할 자료가 전혀 제공되지 않기 때문에 어느 누구도 자신있게 그것을 채용할 엄두를 감히 못내기 때문입니다(우리야 뭐, 서로 믿으니까… 그냥 일단 저지르고 보는 것이지만) ]

    >> 이 부분은 오히려 youknowit님께서 혼동하신 것 아닌지요?
    SEED가 국제화되는데 무슨 결격 사유가 있는 것처럼 들리거든요?
    물론 SEED가 아니라 그 frontend인 ActiveX를 말씀하신 거겠지요.

    하지만 그냥 https 페이지를 보여만 주는 것이 아니라
    전자서명과 결합되는 부분이 바로 frontend의 문제 중 핵심인데,
    그걸 해 주는 구현에는 ‘표준’이 없다는 사실을 깜빡하신게 아니신지.

    [현재 보안접속은 웹브라우저에 내장된 HTTPS 접속 기능을 이용하는 것이 가장 탁월하고, “국제적으로 검증된” 안전성을 제공합니다.]
    >> 이렇게 인용하신걸로 봐서 보안접속 프로토콜과 frontend를 혼동하신 것 같다는 생각이 좀 더 강해지는군요.

  • 몽몽이

    재차 상기해보자면, 우리나라 전자 결제에서의 문제는
    전자서명과 보안접속을 모두 해야 하기 때문에 발생하는 문제입니다.

    이걸 하나의 프레임웍으로 제공해주는 표준은 없는데
    그 구현을 ActiveX로 하고 있는 것에 대해 논쟁이 생기는 것이죠.

    오픈웹에서는 그동안 말로는 아니라고 하지만
    실제로는 자바 애플릿만을 대안으로 인정하면서
    ActiveX의 철폐만을 목적으로 활동했다는 생각이고요.
    (요즘에야 형식적으로 외부 확장 플러그인도 대안에 올리신거 같지만,
    사실 외부 확장 기능에 대해서는 몇마디 논의된 적도 없지 않았나요?)

    전 자바 애플릿이라고 해도
    보안 관점에서는 ActiveX와 별반 다른 입장이 아니라는 판단으로
    자바 애플릿으로 대체하는 쪽으로 추진할 일이 아니라
    근본적으로 프레임웍을 고민하고
    또 관계 기관이 근본적으로 재검토하게 추진되기를 바랬었는데
    또 다른 졸속으로 가려고 하시는 것 같아서 한동안 발걸음을 끊었었습니다.

    기왕에 오랜 시간을 들이고도 결국은 제자리 걸음인데
    이렇게 된 바에 너무 지엽적으로 해결하려 하지 마시고
    좀 거시적으로 접근해가시길 바랍니다.

    • youknkowit

      몽몽이/ “전자서명과 보안접속을 모두 해야 하기 때문에” Yes. It is true that electronic signature and secure connection must both be implemented. But it is wrong to do these two with one plugin. Electronic signature must be separated from secure connection.

      Electronic signature would require a plugin (ActiveX, firefox extention, etc). Secure connection does not need a plugin.

      In all other countries where electronic signature is used, a “signer plugin over SSL/TLS” is the usual approach. No country in the world, that I know of, uses a plugin to implement secure connection.

      • 몽몽이

        그러니까 전자서명하고 결합해서 해야 하니까
        frontend를 쓰게 되는게 문제지
        SEED가 결격 사유가 있는것처럼 쓰시면 안 되잖습니까.

        전자서명하고 보안접속하고 별개라고 설명하시고는
        우리나라 보안접속은 문제있어라고 쓰면
        SEED가 결격 사유가 있는것처럼 보이지 않느냐는 말씀입니다.

        한동안 발걸음을 끊었더니 – 물론 당연하겠지만… –
        제가 낯선 사람이 되어버렸나보군요…

        • dasony

          결합해서 할 필요가 없다는 주장이지 않나요? 브라우저에서 기본적으로 지원하는 SSL위에서 전자서명을 구현하면 되니까요. 그리고 사실 저는 전자서명도 브라우저 기본 탑재되어있는 SSL Client Certificate 등으로 충분하다고 생각합니다.
          SEED가 결격사유가 있다기보단, SEED 자체가 기본 브라우저에서 지원이 잘 안되다보니까 SSL로 가자고 오픈웹에서는 주장할 수 밖에 없죠. 그런데 반대쪽에서는 SSL이 SEED보다 보안적으로 부족하다고 주장하고 있지만, 사실 이를 논의할 방법이 없단 것이 처음 인용하신 부분의 이야기입니다. 그리고 알고리즘 자체가 결격 사유가 (아직) 있지는 않겠지만, SEED가 국제화되는 결격 사유가 없다면 왜 국제화되고 있지 않나요?

          • 몽몽이

            저는 반대로 생각합니다.
            SEED 국제화 같은 쪽에는 오픈웹이 지원을 안하는게 이해가 안되네요.
            오히려 SEED가 기본 지원이 안돼서 불편하니 들어가게 해달라고 그런걸 요구해야 하는게 아닐런지.

          • dasony

            오픈웹은 웹표준을 위한 단체입니다. 웹표준 확대를 위한 단체가 아니고요. SEED가 굳이 타 표준에 비해 특별한 이점이 있다면, 이를 홍보해서 표준화시킬 책임은 SEED를 개발한 쪽에 있죠. 그런데 아직 SEED가 왜 더 좋은지도 정립이 잘되어있지 않은 상황입니다. 무슨 근거로 우리가 이걸 요청하나요?
            게다가 Channy님 등 웹표준 진영에서는 OpenSSL 등의 공개 라이브러리에 SEED ‘알고리즘’이 추가되도록 노력하였고, 지금은 실제로 들어가있는 것으로 알고있습니다. (이부분은 확인을 해봐야겠네요) 하지만 SEED 알고리즘이 추가된다고해도, 현재의 IE뱅킹 시스템이 타 브라우저에서는 돌지않고 있지요.
            브라우저에 어떤 기능이 추가되면 해당 브라우저를 지원해줄 수있는지 알려준다면, 오페라 파폭에 다 추가시킬 수 있습니다. 하지만 현재의 IE뱅킹 시스템은 표준화를 전혀 고려하지않은 채 개발되어 있죠.

          • 몽몽이

            좀… 방준영씨 말대로 d님은 책 좀 보고 말하는게 좋겠습니다. 표준이 무슨 말인지 표준화랑 도대체 무슨 상관인지 그런 것 좀 공부하시지요.

          • http://unipro.tistory.com unipro

            다양한 환경에서 웹을 사용할 수 있도록 하는데 큰 의미가 있습니다. 그런 이유로 표준이 존재한다고 생각하고, 그래서 그것에 맞추어 가자고 하는 것이죠. 이것에는 동의하시나요?
            문제는 표준이 현실을 못따라가는 경우이고 이것때문에 말이 많았습니다. 즉, 표준 방식이 취약하고 우리나라의 방식이 뛰어나다는 의견이 있어서 많은 토론이 있었습니다.
            그런데 실상은 표준 방식의 취약점(SSL strip 등)은 우리나라의 방식에서도 고스란히 가지고 있었습니다. 표준 방식이 취약하다는 상당수의 경우도 이미 해결이 가능합니다(SSL3/TLS, SSL Client Certificate 등).
            부인방지에 대한 부분에 대해서는 여러 의견이 있는 것으로 알고 있습니다. 안티 바이러스와 키보드 보안에 대해서도 논의가 더 진행되어야 할 것으로 보입니다.
            몽몽이님! 접근 방법은 고려하지 말고, 특정 OS/브라우저로 제한된 현재의 상황을 개선해는데는 같은 의견입니까? 우리나라의 웹환경을 개선하여 발전하기 위한 토론이라면 좋은 결과를 만들겠지만, 단지 반대의견을 개진하기 위한 비판이라면 꼬투리 잡기와 다툼만 생길 뿐이겠죠. 좋은 결과를 같이 보았으면 좋겠습니다.

          • 일반인

            우리나라의 현재 인터넷뱅킹은
            피싱에 속수무책입니다.

            액티브X 관리자 권한 설치됨.
            은행에서 YES 누르라고 함.

            예)
            고객이 피싱 사이트에 접속
            고객이 피싱 사이트를 은행이라고 착각, 또는 믿음.
            이 경우, 이체까지 될 수 있습니다. 가능성 매우 높음.

            일단, 피싱 사이트에 접속해서 믿으면, 계좌이체를 막을 수 있는 방법이 없을 것 같습니다.
            그래서 피싱에 걸리지 않도록 하는 것이 굉장히 중요합니다.
            액티브X를 배포하는 현행 인터넷뱅킹 환경은 피싱에 굉장히 취약합니다.
            그러므로 액티브X를 배포하는 방식이 없어져야 되겠죠.
            그 공백을 ssl로 매우자는 것입니다.

          • dasony

            만약 정말 현재 SEED등이 기존 표준으로는 지원할 수 없는 기능을 지원하기 위해 어쩔 수 없이 사용하는 것이었다면, 애초에 디자인 단계부터 표준화를 고려하여 디자인하는게 좋았겠죠. API를 정의하고 해당 API만 지원하면 브라우징이 가능하도록 디자인한 후, IE 등 일부 브라우저에서 한해 ActiveX 등의 방식을 통해 지원할 수 있도록 하였다면, 타 브라우저에서는 해당 API만 지원하면 인터넷 뱅킹이나 결제가 자동으로 되었을 겁니다. 지금은 오픈 소프트웨어를 아무리 고쳐도 (IE용 자바스크립트와 ActiveX를 그대로 지원하지 않는 한) 뱅킹을 지원할 방법이 없습니다.

          • 이미지복구솔루션

            옛날에는 ssl이 유료였는데 요즘에는 무료이니 ssl쓰면 되지않습니까?

  • 몽몽이

    그만 쓸려고 했는데…

    우리나라 현실이나 외국의 전자 결제 보안 현실 – 마치 외국은 보안 튼튼 천국인것처럼 말씀하시지만 – 을 볼 때 전자서명과 보안접속을 결합해서 쓰자는 사고 자체는 일단 타당하다고 봅니다.

    그럼 결국 오픈웹이 궁극적으로 추구하는(추구해야 할) 목적도 그렇고… frontend에 불필요한 제약을 없애라 그게 문제 아닙니까.
    이를테면 ActiveX 아니면 심사를 안 해준다 이런 거.

    그런데 무슨 RFP를 쓰고 그러십니까.
    자바 애플릿이나 확장 플러그인을 대안이라 본다는둥 그런 말은 왜 쓰십니까. 그거나 금결원이 하는 말이나 뭐가 다릅니까.

    소소하게는 심사 제약, 거시적으로는 근본적으로 아키텍처상의 구성 요건이 문제인 것이지요.
    아키텍처도 개념적/논리적/구현 등 여러 level에서 정의되어야 하겠습니다.
    그렇게 구성 요소를 재 정의/정립해가야 한다는게 제 생각입니다.

    공연히 대안의 구체적인 요소를 거명해가며 운동을 하셨지만 그 결과는 어떻습니까. 그리고 애당초 이렇게 될 걸 정말 모르셨나요.
    무슨 서명운동이니 이런거 하시며 똑같은 일을 한번 더 하시려는 모습은 정말 진의를 의심케 합니다.

    • http://filmstyle.net filmstyle

      그만쓰시지 그러셨어요. 비꼬는 말로밖에는 안들리고, 어짜피 이렇게 될껄 뭐하냐 라는 뉘앙스만 풍깁니다.

      • 몽몽이

        너무 ‘당장의 대안’만 가지고 해결을 서두른 것이 문제가 아닌가 합니다.
        그리고 그런 과정에서 본의 아니게 특정 대안에 의존적으로 되어간 것은 아닌가 싶기도 하고요.
        어쨋거나 현재 결과는 이런데, 서명운동 등으로 돌파구를 찾으려 할 것이 아니라 보다 장기적인 방안을 도모하는게 낫지 않을까 하는 것입니다.

    • VongZa

      뭐.. 오랜만에 오셨다고 하셨으니, 최근의 글을 다 못읽어 보셨을 수도 있을 것 같습니다만, Channy님 블로그에 보시면 오픈웹 사이트에서 여러가지 주제들이 섞인 채로 토론이 이루어지고 있어서, 주제별로 토론의 줄기라고 할까 오픈웹에서 주장하는 의견이랄까 그런 것들을 알기 어렵기 때문에, 백서같은 것을 만들고 있다는 글이 있습니다. 그 작업이 끝나면 말씀하신 구성요소의 재정의/정립은 어느정도 될 거라고 생각합니다. 기다려보시죠.

      그리고 한가지 말씀드리고 싶은 것은, 오픈웹에서 이야기하는 것이 우리나라가 보안이 부실하고 외국은 튼튼하다는 것 보다는, 외국과 비교했을 때 우리나라에서 사용하는 보안 “방법”이 옳지 않다 것으로 저는 이해하고 있습니다.

      • 몽몽이

        Channy님 작업의 허상에 대해 아직 못 들으셨나보군요… 계속 기다려 보시지요 뭐가 나오나
        Channy님 스스로 자폭하신거 모르시나

  • 몽몽이

    아시는 분은 아시겠지만 제가 다른데 가서 여기 많이 “깠습니다”
    그런데 여기서 안하던 말 한거 아니고 없는 말 지어낸거 아닙니다
    제가 희망하는건 협소한 대안만이 궁극적 해법인양 특히 “소송”이라는 방법만을 통해 결과를 얻고자 하지 말고 좀 거시적으로 전자 결제란 것이 어떻게 돌아가야 할 것인지 큰 프레임워크를 잡아보자는 것입니다.
    물론 오픈웹에서도 모토는 그랬지만 실제로는 그러지 못했다는거 다들 공감하시지 않나요?
    그리고 전문단체의 활동 방식이 소송 뿐이랍니까?
    소송에만 너무 연연하지 않는다면 아직 시간은 많습니다. 이제부터 시작이라고 해도 되지 않을까요?

  • 몽몽이

    dasony님 이거 하난 인정하셨으면 좋겠습니다. 안타깝게도 표준화하고 전자서명을 이용한 전자 “결제”하고는 아무 상관도 없습니다.
    어떤 식으로 해서 우리가 하는 것처럼 전자서명을 이용한 전자 결제 방식이 웹 브라우저별 플러그인 각개전투보다는 더 포괄적인 방법으로 지원이 되는 기적같은 일이 벌어지더라도, 그런건 “표준화”는 아니지 않습니까.

  • http://twitter.com/kimys0202 Kim Yoonsik

    이 글 정말 초보자들도 쉽게 이해할 수 있을 만큼 정리가 잘 되어있네요