SSL/TLS의 MITM 취약성
mongmong
취약성이 있으면 그 취약점이 정확히 어떤 것인지 아는 것도 중요하다고 생각해서
제가 아는 한도에서 설명을 해보겠습니다.
말 그대로 MITM (man in the middle, 중간개입) 취약성인만큼, 그 취약성이 시스템권한 탈취를 하는 원격
exploit 과 같은 공격과는 전혀 다르고 서버/클라이언트에 대한 권한이 없이도 가능한 공격방식입니다.
SSL MITM 의 공격방식은 네트워크상에서 서버와 클라이언트의 중간위치에 있는 공격자(proxy 역할)가 SSL의
handshake step 중 share key(대칭 비밀키) 교환단계에서 가짜 share key로 바꾸는 방법으로 데이터를
변조하거나 id/pass 를 복호화해내는 것입니다.
공격자 A는 클라이언트가 서버에게 전송하는 share key 를 가로채어서 가짜 share key로 바꾼 다음 서버에게 전송합니
다. 그러면 서버는 가짜 share key 를 암호한 데이터를 공격자A에게 보내고 공격자A는 가짜 shared key로 데이터
를 복호화하고 다시 클라이언트에게서 가로챈 shard key로 암호화해서 클라인언트에게로 전송하는 공격방식입니다.
문제는 mitm 공격으로 서버와 클라이언트는 데이터가 변조되어도 전혀 피해를 눈치채지 못하는 것에 대해 심각성이 있습니다.
단, 그 공격이 가능할려면 네트워크상의 제약이 따릅니다.
제가 아는 한도에서 가능한 조건을 생각해보면
1. 동일 서브넷상의 공격자가 arp spoofing 으로 패킷을 가로채어 변조가 가능할 때.
2. dns 변조(dns spoofing)가 가능한 무선 AP로 피해자들의 접속을 유도하여 패킷변조가 가능할 때
mitm 공격을 할려면 공격자는 패킷의 라우팅을 제어할 수 있기 위해 피해자와 동일서브넷상에 있거나 피해자가 있는 네트워크단
에 제어권이 있어야 합니다.
이 외에 기술적으로 ssl/tls 가 mitm 공격에 노출될 수 있는 어떤 조건들이 있는 지 아시면 알려주시고,
제 설명에 오류가 있다면 지적해주시면 좋겠습니다. ^^
그리고, 이러한 ssl mitm 공격메커니즘을 살펴보건데,
ssl/tls 가 mitm 공격에 취약하다면 현재 인터넷뱅킹이 activex 보안플러긴을 사용하여 보안접속하는 것도 매 한가지
로 mitm 에 취약할 것으로 생각됩니다.
단지 activeX 보안접속은 ssl처럼 handshake spec 이 공개되어 있지 않아서 그걸 알아내는 데 좀 더 시간이 소
요되는 차이가 있겠지요.
즉, 두 가지 방식다 mitm 공격에 대해 네트워크 보안성을 높여야 할 문제이지
ssl/tls 만 취약하다는 건 아니라고 생각합니다.
Matt Oh
youknowit
자세한 기술 설명, 대단히 감사합니다. 그러나, 말씀 하신 취약점은 혹시 SSL v. 2 에서 문제가 되었던 것이 아닌지요?
http://en.wikipedia.org/wiki/Transport_Layer_Security#Security 참조.
SSL v.3 그리고, 현재는 거의 대부분의 응용프로그램이 default 로 채택하는 TLS 에서는 선생님께서 지적하셨던 취약점
이 대부분 보완된 것으로 저는 이해합니다.
그리고, Client-authenticated TLS handshake 의 경우(서버도 SSL 인증서를 제시하고, 접속자도 자
신의 user certificate 을 제시하는 접속방법)에는 지적하신 공격방법은 현실적으로 불가능한 것으로 생각합니다.
SSL v.2는 현재 대부분의 웹브라우저가 기본적으로 사용불가하게 설정되어 있고, 오페라 웹브라우저는 아예 제거하였습니다.
On Apr 9, 12:37 pm, Matt Oh <oh.jeongw...@gmail.com> wrote:
> 아 한국은 AP들이 많으니 rogue AP를 이용하는 간단한 방법도 있울 것 같습니다.
>
> 2009/4/8 mongmong <flyto...@gmail.com>
mongmong
저로서는 SSL V2, V3 / TLS 스펙변경사항에 대해서는 잘 알지 못합니다만,
별도로 신원확인절차가 들어가지 않는 이상 SSL MITM 취약성은 여전히 존재할 것입니다.
------------------------------------------------------- (인용)
-------------------------------------------------------
그리고, Client-authenticated TLS handshake 의 경우(서버도 SSL 인증서를 제시하고, 접속자도
자
신의 user certificate 을 제시하는 접속방법)에는 지적하신 공격방법은 현실적으로 불가능한 것으로 생각합니다.
--------------------------------------------------------------------------------------------------------------------
↑
ssl mitm 이 가능할려면 보안의식이 낮은 사용자가 ssl인증서 보안경고창이 떠도 무심코 "예"를 클릭해야만 가능합니다.
그렇지만 Client-authenticated TLS handshake 처럼 클라이언트의 신원을 확인하는 과정의
handshake 를 한다면
서버측에서 가짜 certificate 에 속아줄리가 만무하겠지요.
잘 아시다시피 Client-authenticated TLS handshake으로 클라이언트의 신원확인이 되려면
클라이언트가 자체발급한 certificate 로는 되질 않고 , 전자서명용도는 아니지만 마치 ActiveX 보안접속시 이체거래
에 사용되는 공인인증서처럼 공인된 기관으로부터 신원확인용 인증서(공개키) 구매가 필요하겠지요.
그래도 중요한 것은 ActiveX처럼 별도 플러그인으로 하지 않고 브라우저자체 기능만으로 구현이 가능하다는 점에서는 서로 다릅니
다.
하지만, 실제로는 외국은행 인터넷뱅킹시에도 따로 SSL/TLS 클라이언트 인증과정은 거치지 않는 것으로 보입니다.
보안경고에 "예"를 클릭한 사용자에게로 책임을 전가하는 것인지...
그리고 아직 IE 6.0 사용자들이 꽤 많은데요.
사람이란 그저 자신이 오래 쓴 익숙한 것이 바뀌기는 것에 대해 변화를 싫어하게 마련인지라..
습관이 무섭다라는 말이 이래서 나온 거겠죠.
youknowit
인인증서가 바로 클라이언트 인증서(user certificate) 입니다.
일본의 은행들은 이처럼 개인 인증서를 제시하도록 요구합니다. 이것(즉, 개인인증서 로그인)을 구현하는데에는 별도의 플러그인이 필
요 없습니다. 웹브라우저에 이미 이 수준의 작업(로그인)에 필요한 서명기능이 있습니다.
구글에서 client certificate authentication 을 검색하시면, 서버 세팅을 어떻게 하면 클라이언트 웹브라
우저로 하여금 인증서 로그인을 하도록 할 수 있는지에 대한 설명을 적은 페이지들이 다수 있습니다. (물론, 이렇게 하려면, 공인
인증서를 pfx 파일형식으로 미리 내보내기 해두어야 하지요)
youknowit
key 자체가 없습니다.
대신에, 클라이언트는 자신이 임의로 생성한 난수(random number)를 서버인증서로 암호화 한 값을 서버에게 보냅니다.
이 값을 중간에서 가로채 본들, 서버인증서에 상응하는 개인키(오직 서버만이 가지고 있지요)가 없는 공격자는 난수 값을 확인할
수 없습니다.
shared key는 클라이언트가 암호화 해서 보내온 난수(RN)를 서버가 복호화 해서 확인한 순간부터 각자의 컴퓨터에서 (동일
한 RN에서 출발하여) 독립적으로 생성됩니다(결과 값은 물론 같습니다. 그렇지 않으면 "shared key" 가 될 수 없겠지
요). 이상은 서버인증서에만 기초한 SSL/TLS handshake 입니다.
client certificate authentication 까지 추가된 Handshake 의 경우에는, 마지막 단계에서
client 컴퓨터의 MAC 값까지 확인하는 과정이 있습니다. 따라서 MITM 는 현실적으로 불가능합니다.
http://en.wikipedia.org/wiki/Transport_Layer_Security 을 보시면, 보다 상세한 설명
이 있습니다.
youknowit
것들인 것으로 보입니다.
서버가 SSLv2 를 아예 disable 시키거나, 클라이언트가 Firefox3나 구글크롬, MS IE7 이후 등, 비교적 최
근 버전의 웹브라우저를 사용하는 경우, 더 이상 MITM 는 현실성이 없는 시나리오라고 생각합니다.
아파치2 서버의 경우, 설정파일 중, ssl.conf 에서 "SSLProtocol all -SSLv2" 를 uncomment 하
면, SSL2로는 아예 접속할 수 없게 설정이 됩니다.
On 4월9일, 오후4시07분, youknowit <keechang....@googlemail.com> wrote:
> SSL v.3 와 TLS 의 경우, shared key 가 네트웍을 오가지는 않습니다. 따라서 중간에 누가 가로챌 shared
> key 자체가 없습니다.
>
> 대신에, 클라이언트는 자신이 임의로 생성한 난수(random number)를 서버인증서로 암호화 한 값을 서버에게 보냅니다.
> 이 값을 중간에서 가로채 본들, 서버인증서에 상응하는 개인키(오직 서버만이 가지고 있지요)가 없는 공격자는 난수 값을 확인할
> 수 없습니다.
>
> shared key는 클라이언트가 암호화 해서 보내온 난수(RN)를 서버가 복호화 해서 확인한 순간부터 각자의 컴퓨터에서 (동일
> 한 RN에서 출발하여) 독립적으로 생성됩니다(결과 값은 물론 같습니다. 그렇지 않으면 "shared key" 가 될 수 없겠지
> 요). 이상은 서버인증서에만 기초한 SSL/TLS handshake 입니다.
>
> client certificate authentication 까지 추가된 Handshake 의 경우에는, 마지막 단계에서
> client 컴퓨터의 MAC 값까지 확인하는 과정이 있습니다. 따라서 MITM 는 현실적으로 불가능합니다.
>
> http://en.wikipedia.org/wiki/Transport_Layer_Security을 보시면, 보다 상세한 설명
정 태영
그런 사용자들을 끌어안을 수 밖에 없는 (그러면서 왜 FF, Opera, Safari,
Chrome 사용자들을 끌어안는데 소극적인지 모르겠지만) 상황 상 문제가 있을
수 있다는 것은 인정하는게 좋을 것 같습니다.
그런데 (거기서 거기인 것으로 보이는) XecureWeb, INISafeWeb 등에서도 동일
한 문제가 있을텐데 SSL에 대해선 그렇게 비판하면서도 XecureWeb 이나
INISafeWeb 등 만으로는 안된다는 얘기는 왜 안나오는지 모르겠습니다.
어쨌거나 전자 서명 등이 2차적 보안 장치가 될 수 있으니 큰 문제가 없다고
생각되는데...
2009. 04. 10, 오전 9:38, youknowit 작성:
youknowit
야 하지 않을까요? 오락물이라거나, 보안과 별 관련이 없는 콘텐트라면, 가급적 하향 호환성을 널리 확보해서 최대한 많은 이용자
를 끌어안아야 하겠지요.
그러나, 뱅킹 등 보안이 필수적인 서비스의 경우, 이미 취약점이 드러난 SSL2 를 "끌어안고 갈" 이유는 전혀 없습니다.
SSL2는 즉각 disable 시키고, 안전한 프로토콜(SSL3/TLS1)을 사용하도록 해야 하지 않을까요? IE7은 SSL3/
TLS1 을 기본으로 사용합니다. 오페라, 파이어폭스3 등은 아예 SSL2는 폐기했습니다.
국내 은행들이 은근히 고객들이 IE6를 계속 사용해 주기를 바라는 이유는 액티브X 플러그인 설치가 상대적으로 쉽기 때문이라고 짐
작해 봅니다. IE7이나, IE8에서는 월등 많은 고객문의가 쇄도 하지 않겠어요?
현재 방식(플러그인 의존 방식)은 조만간 한계에 부딛칠 것으로 저는 생각합니다. 막다른 골목이랄까...
ds1405s
얼마전에 발표된 내용은 ssl strip입니다..
http://www.circleid.com/posts/20090219_https_web_hijacking/
https://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf
youknowit
sslstrip 에 대해서 mountie 님이 이미 댓글을 남기신 것으로 기억합니다만, client certificate
authentication 을 채택하면 만족스럽게 해결될 문제라고 생각합니다.
sslstrip 은 anonymous SSL session (즉, 서버만이 인증서를 사용하고, user는 자신의 인증서를 제시하
지 않는 접속) 에서나 가능한 공격입니다. 구글, 페이팔 등 막대한 수의 이용자를 상대로 서비스를 제공하는 경우에는 이용자들에
게 일일이 개인인증서를 요구할 수 없지요.
그러나, 은행은 다릅니다. client authenticated session 을 채택할 수 있지요. (공인인증서 저장 양식을
pfx 나 pkcs#11 으로 하면 이용자에게 아무런 불편도 없고, 별도의 플러그인도 필요 없겠지요)
On 4월10일, 오전10시25분, ds1405s <ds14...@gmail.com> wrote:
> ssl sniff 취약점에 대하여서는 최신 브라우저들이 어느정도 대응을 했지만,,
> 얼마전에 발표된 내용은 ssl strip입니다..
>
ds1405s
사용자에게는 http 연결을 위한 handshake 조차 이루어지지 않는 것으로 보입니다.
(자신이 접속하는 페이지가 SSL 연결을 요구하는지조차 모르는,,,)
handshake 시 서버인증서와 클라이언트 인증, 키교환 등의 과정을 거치는데
중간 공격자가 이런 과정을 대신하고 http가 사용자에게 전송되기 때문에
클라이언트 인증 기능이 제대로 동작하지 않을 것 같네요..
그래서 Chrome은 WhiteList방식(반드시 SSL 연결이어야 하는 사이트 목록)으로
약간의 대처를 하고있다고 하는 것 아닐런지요.
On 4월10일, 오전11시48분, youknowit <keechang....@googlemail.com> wrote:
> 네. 알고 있습니다.
>
> sslstrip 에 대해서 mountie 님이 이미 댓글을 남기신 것으로 기억합니다만, client certificate
> authentication 을 채택하면 만족스럽게 해결될 문제라고 생각합니다.
>
> sslstrip 은 anonymous SSL session (즉, 서버만이 인증서를 사용하고, user는 자신의 인증서를 제시하
> 지 않는 접속) 에서나 가능한 공격입니다. 구글, 페이팔 등 막대한 수의 이용자를 상대로 서비스를 제공하는 경우에는 이용자들에
> 게 일일이 개인인증서를 요구할 수 없지요.
>
> 그러나, 은행은 다릅니다. client authenticated session 을 채택할 수 있지요. (공인인증서 저장 양식을
> pfx 나 pkcs#11 으로 하면 이용자에게 아무런 불편도 없고, 별도의 플러그인도 필요 없겠지요)
>
> On 4월10일, 오전10시25분, ds1405s <ds14...@gmail.com> wrote:
>
> > ssl sniff 취약점에 대하여서는 최신 브라우저들이 어느정도 대응을 했지만,,
> > 얼마전에 발표된 내용은 ssl strip입니다..
>
> >http://www.circleid.com/posts/20090219_https_web_hijacking/https://ww......
Jung Tae-young
적용하기 쉽지 않을 것 같은데요.
컴퓨터를 잘 다루지 못하는 분들이 가이드를 통해 어떻게든 인터넷 뱅킹을 하
는데 성공할 수 있을지는 모르지만, 과연 인터넷 뱅킹이 끝나고 나서 설치했
던 인증서를 잘 제거하고 일어날지 의문입니다.
관련해서 또 다른 문제를 야기시킬 수도 있을 것 같네요.
youknowit 쓴 글:
> 네. 알고 있습니다.
>
> sslstrip 에 대해서 mountie 님이 이미 댓글을 남기신 것으로 기억합니다만, client certificate
> authentication 을 채택하면 만족스럽게 해결될 문제라고 생각합니다.
>
> sslstrip 은 anonymous SSL session (즉, 서버만이 인증서를 사용하고, user는 자신의 인증서를 제시하
> 지 않는 접속) 에서나 가능한 공격입니다. 구글, 페이팔 등 막대한 수의 이용자를 상대로 서비스를 제공하는 경우에는 이용자들에
> 게 일일이 개인인증서를 요구할 수 없지요.
>
> 그러나, 은행은 다릅니다. client authenticated session 을 채택할 수 있지요. (공인인증서 저장 양식을
> pfx 나 pkcs#11 으로 하면 이용자에게 아무런 불편도 없고, 별도의 플러그인도 필요 없겠지요)
--
오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다.
dasony
해당 기능은 편의성이 많이 떨어지는 편입니다. 그래서 USB 등에 저장해놓고
쓰기는 정말 귀찮게 되어있죠. 그래서 일반 사용자들이 쉽게 쓸 수 있는 UI를 가진
Certificate 관리 프로그램을 추가로 제작하여 배포해야 할 것입니다.
이런 프로그램은 IE+ActiveX로 작성해도 상관없겠죠. 타 브라우저나 타 플랫폼은
브라우저의 기능을 사용하거나, 불편한 사람이 직접 만들어 배포할 수도
있을테니까요.
Jung Tae-young
다. 플러그인이든 activeX 어쨌건 하나만 설치하면 되도록요. 그 전에 공인
인증 API를 표준화/공개 된다는 가정 하에...
dasony 쓴 글:
swlee
오픈웹에서 이런 진지한 보안 기술에 대한 논의가 될줄이야...
이왕 시작했으니
보안관계자 분들이 우려하는 최신 해킹기법에 대한 SSL의 한계에 대해서
정확하게 이해하는 것이 필요할 것 같습니다.
아래는 온라인 뱅킹 시스템을 공격하는 악성코드에 대한 경고입니다.
http://www.trustdefender.com/blog/2009/02/28/banking-malware-bankpatchc-shows-that-the-bad-guys-are-extremely-innovative/
BHO 형태로 동작하기 때문에 SSL로는 방어가 불가능 합니다.
내용에도 SSL로 암호화된 HTML 에서도 동작한다는 코멘트가 있네요,,,
이미 2004년에 BHO 로 동작하는 것은 SSL 로 방어가 불가능 하다고 포스팅 되어 있습니다.
http://news.netcraft.com/archives/2004/06/30/hackers_manipulating_internet_explorer_addons.html
"It ultimately installs its keylogger trojan, which scans for https
sessions connecting to URLs of popular banks (including Citibank,
WestPac, Barcklays and HSBC) and then intercepts outbound data from IE
before it is encrypted using the Secure Sockets Layer (SSL) protocol."
이런 악성코드에 대항하기 위해서는 아래 4가지 방법밖에는 없을 것 같습니다.
1, IE를 사용하지 않는다.(BHO 가 IE 종속적인 기술이기 때문에)
2. 바이러스 백신 회사가 미친듯이 열심히 일한다.
3. 이런 악성코드에 대한 피해는 감수한다.
4. APPLICATION 레벨에서 방어가 될 수 있도록 ETE 보안접속 모델을 한층 더 강화시킨다..
한가지 재미있는 점은 제가 자료를 검색하면서
온라인 뱅킹 악성코드의 위험과 경고에 대해 포스팅 된 사례가
국내보다는 외국이 압도적으로 훨씬 많았습니다.
국내 인터넷 뱅킹 보안환경이 그나마 선방하고 있다는 느낌입니다.
구글에서 banking malware 로 검색해 보니 어찌나 많은 악성코드가 나오던지,,,
또 재미있는것은 파폭에서 플러그인으로 동작하는 악성코드입니다.
http://blogs.zdnet.com/security/?p=2264
구글에서 FireFox banking malware 로 검색하니 어찌나 많던지,,,
SSL만으로 안전하다는 외국 은행들 보다는
인터넷 뱅킹시 다양한 보안 환경을 알아서 제공하는
국내 은행들이 그나마 나은건 아닐까요?
On 4월10일, 오전11시48분, youknowit <keechang....@googlemail.com> wrote:
> 네. 알고 있습니다.
>
> sslstrip 에 대해서 mountie 님이 이미 댓글을 남기신 것으로 기억합니다만, client certificate
> authentication 을 채택하면 만족스럽게 해결될 문제라고 생각합니다.
>
> sslstrip 은 anonymous SSL session (즉, 서버만이 인증서를 사용하고, user는 자신의 인증서를 제시하
> 지 않는 접속) 에서나 가능한 공격입니다. 구글, 페이팔 등 막대한 수의 이용자를 상대로 서비스를 제공하는 경우에는 이용자들에
> 게 일일이 개인인증서를 요구할 수 없지요.
>
> 그러나, 은행은 다릅니다. client authenticated session 을 채택할 수 있지요. (공인인증서 저장 양식을
> pfx 나 pkcs#11 으로 하면 이용자에게 아무런 불편도 없고, 별도의 플러그인도 필요 없겠지요)
>
> On 4월10일, 오전10시25분, ds1405s <ds14...@gmail.com> wrote:
>
>
>
> > ssl sniff 취약점에 대하여서는 최신 브라우저들이 어느정도 대응을 했지만,,
> > 얼마전에 발표된 내용은 ssl strip입니다..
>
> >http://www.circleid.com/posts/20090219_https_web_hijacking/https://ww......
> > > > > 면, SSL2로는 아예 접속할 수 없게 설정이 됩니다.- 따온 텍스트 숨기기 -
>
> - 따온 텍스트 보기 -
swlee
정신이 없다보니 이곳에 올라 갔네요.,
무슨생각하고 사는건지.. 죄송합니다.
On 4월10일, 오후1시19분, swlee <Bang...@gmail.com> wrote:
> 열띤 토론의 분위기네요..
> 오픈웹에서 이런 진지한 보안 기술에 대한 논의가 될줄이야...
>
> 이왕 시작했으니
> 보안관계자 분들이 우려하는 최신 해킹기법에 대한 SSL의 한계에 대해서
> 정확하게 이해하는 것이 필요할 것 같습니다.
>
> 아래는 온라인 뱅킹 시스템을 공격하는 악성코드에 대한 경고입니다.http://www.trustdefender.com/blog/2009/02/28/banking-malware-bankpatc...
> BHO 형태로 동작하기 때문에 SSL로는 방어가 불가능 합니다.
> 내용에도 SSL로 암호화된 HTML 에서도 동작한다는 코멘트가 있네요,,,
>
> 이미 2004년에 BHO 로 동작하는 것은 SSL 로 방어가 불가능 하다고 포스팅 되어 있습니다.http://news.netcraft.com/archives/2004/06/30/hackers_manipulating_int...
>
> "It ultimately installs its keylogger trojan, which scans for https
> sessions connecting to URLs of popular banks (including Citibank,
> WestPac, Barcklays and HSBC) and then intercepts outbound data from IE
> before it is encrypted using the Secure Sockets Layer (SSL) protocol."
>
> 이런 악성코드에 대항하기 위해서는 아래 4가지 방법밖에는 없을 것 같습니다.
> 1, IE를 사용하지 않는다.(BHO 가 IE 종속적인 기술이기 때문에)
> 2. 바이러스 백신 회사가 미친듯이 열심히 일한다.
> 3. 이런 악성코드에 대한 피해는 감수한다.
> 4. APPLICATION 레벨에서 방어가 될 수 있도록 ETE 보안접속 모델을 한층 더 강화시킨다..
>
> 한가지 재미있는 점은 제가 자료를 검색하면서
> 온라인 뱅킹 악성코드의 위험과 경고에 대해 포스팅 된 사례가
> 국내보다는 외국이 압도적으로 훨씬 많았습니다.
>
> 국내 인터넷 뱅킹 보안환경이 그나마 선방하고 있다는 느낌입니다.
> 구글에서 banking malware 로 검색해 보니 어찌나 많은 악성코드가 나오던지,,,
>
> 또 재미있는것은 파폭에서 플러그인으로 동작하는 악성코드입니다.http://blogs.zdnet.com/security/?p=2264
> > - 따온 텍스트 보기 -- 따온 텍스트 숨기기 -
Jung Tae-young
> 이런 악성코드에 대항하기 위해서는 아래 4가지 방법밖에는 없을 것 같습니다.
> 1, IE를 사용하지 않는다.(BHO 가 IE 종속적인 기술이기 때문에)
악성 코드의 위험성이 발표된 사례가 국내보다는 외국이 압도적으로 많다는
점이 국내 인터넷 뱅킹이 더 선방하고 있는게 아니냐는 결론은 조금 이르다고
생각합니다. 관련 인력의 수 차이도 있겠고, 국내에서는 문제점을 알아도 공
개하지 않는 성향(자기만 알고 있으려고 하는)이 매우 극심하다는 것을 고려
해야니까요.
swlee
> 점이 국내 인터넷 뱅킹이 더 선방하고 있는게 아니냐는 결론은 조금 이르다고
> 생각합니다. 관련 인력의 수 차이도 있겠고, 국내에서는 문제점을 알아도 공
> 개하지 않는 성향(자기만 알고 있으려고 하는)이 매우 극심하다는 것을 고려
> 해야니까요.
보안 기술에 대해서는 그럴수도 있을 것입니다.
하지만 악성코드만큼은 다릅니다.
국내도 남보다 먼저 발견해서 보고하는것은
외국과 결코 다르지 않습니다.
백신업체 입장세서 새로운 악성코드의 발견및 발표, 백신 업데이트는
사활이 걸린 문제인데요..
새로운 포스트 주게로 글 올렸습니다.
제 글에 대한 반론및 의견은 새로운 포스트에 부탁 드립니다.
이 쓰레드에서 코멘트로 올린점
다시 사과 드립니다.
youknowit
지만, 공인인증서가 현재 저장되는 방식이 좀 독특해서 웹브라우저에 기본 탑재된 user certificate login 기능을
그대로 사용할 수는 없습니다(보안 토큰에 PKCS#11 방식으로 저장되는 공인인증서인 경우에는 별 문제 없습니다만). 고객이 자
신의 공인인증서를 pfx (PKCS#12 양식)으로 변환해야 하는데, 이 방법을 아는 사람이 많지는 않지요(현재도 가능하긴 하지
만: 인증서 내보내기)
그러나, 서버가 EV 인증서를 채택할 경우, sslstrip 공격은 거의 현실성이 없게 됩니다. sslstrip 공격은 고객이
웹주소 등을 꼼꼼히 확인하지 않고 거래를 진행한다는 행태(user behaviour)에 의존하는 공격입니다. 그러나, EV 인증
서를 서버가 채택하면, 로그인 등 https 접속 페이지 주소창에는 눈에 "확 띄는" 큼직한 씰(seal) 이 나타납니다. 예
를 들어, 다음(daum) 로그인 페이지를 보시기 바랍니다.
은행이 고객들에게, 로그인 할때 주소창에 씰이 나타나는 것을 확인하라고 안내할 경우, 그런 씰이 없는데 로그인 하고 거래하는 고
객의 수는 현저히 줄어듭니다. EV 인증서가 고객에게 제공하는 alert 효과는 보안경고창에 버금갑니다.
skon
기술적인 부분에서 보다 제대로된 공부가 필요한 것 같습니다.
혹시나 하는 마음에 이경문님 홈페이지(http://www.gilgil.co.kr)에 찾아가서 글을 살펴봤더니 논의된 얘기들이 기
술적으로 오류가 많다고 홧김에 쓰신 거 같더군요.. 틀렸다는 얘기만 쓰여있어서 안타깝지만 해당하는 보안문제는 알아서 공부해라는
식인 것 같습니다. (물론 전문가분들은 해당 기술 논의를 살펴보는 것으로 무엇이 문제고 어떻게 대응해야 해결책이 되는지를 알 것
라고 생각합니다만, 컴퓨터에 어느정도 관심이 있었던 저의 경우에도 쉽게 알기 어렵더군요..)
원래 오픈웹의 취지는 국내 인터넷 환경에 대한 정책적 방향성 제시와 감시라고 생각했었습니다만, 그간의 소송으로 인해 기술적 대
안 조차도 제시해야되는 사태에 직면하게 되었군요.. 오픈웹 취지에 동의하는 보안전문가 영입해서 오픈웹의 기술적 기초를 마련해야
할 것 같습니다. 그렇지 않고서는 현재의 불만에 가득찬 보안전문가와는 점점더 척을 지게 되기만 할 것 같군요..
전문가도 아닌 오픈웹에서 왜 기술적으로 완비된 결과물을 제시해야하는지는 모르겠지만...
안타깝습니다.
Matt Oh
--
-matt
정 태영
강조해주는 정도가 다릅니다. 일례로 사파리에서는 해당 내용이 있다는 것을
알고 찾아보기 전에는 쉽게 눈에 띄질 않습니다.
뭐 어쨌거나 지금까지 나왔던 보안 문제에 대한 내용을 조금 정리해봤습니다.
http://b.mytears.org/2009/04/1936
아래 슬라이드에 있는 내용을 많이 참고했는데, 혹시 제가 잘못 이해한 게 있
다면 지적 부탁드립니다.
https://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf
2009. 04. 10, 오후 11:45, youknowit 작성:
> EV 인증서가 고객에게 제공하는 alert 효과는 보안경고창에 버금갑니다.