지난 글에 이어서 사태를 정리해 보겠습니다.
지난 10여년간 ‘보안접속‘과 관련하여 벌어진 상황은 다음과 같습니다:
애초(2000.7)부터 아무런 부가 프로그램도 설치할 필요 없이, 훨씬 더 강력하고, 더 안전하고 간편한 보안접속이 https 로 가능한데도, 웹서버들은 굳이
- 별도의 플러그인을 돈을 주고 사고(서버 솔루션 구입가격에 포함),
- 고객들로 하여금 모두 그 플러그인을 설치하도록 하고(“반드시 ‘예’를 누르시라”),
- 설치오류가 생기는 무수한 이용자들의 문의 전화를 일일이 응대해야 하고,
- MS 사가 IE 웹브라우저나 윈도우 운영체제를 업그레이드 하면, 보안접속 플러그인의 설치, 실행이 전면 중단되거나 심각한 장애를 겪고,
- 이 모든 것도 모자라, 자기 웹사이트 전체를 프레임으로 뒤덮어 고객들이 그 사이트의 하위 페이지를 링크도 할 수 없고, 즐겨찾기로 등록할 수도 없고, 웹브라우저의 ‘뒤로가기’ 버튼도 사용할 수 없도록 ‘골탕 먹이고’,
- 프레임 때문에 자기 웹사이트마저 제대로 검색되지 않으므로, 잠재적 고객이 찾아올 수조차 없도록 꽁꽁 숨어온 셈입니다.
국내 보안 업체들이 90년대 후반에 개발한 ’128bit SEED 보안접속’ 프로그램은 이런 여러 ‘특징’ 들을 두루 구비하고 있습니다. ‘전자서명’이 전혀 필요 없고, id/password 로 로그인만 하거나, 이름/주민등록번호로 실명확인만 하면 되는 서비스에까지 이런 프로그램을 그냥, 무조건, “쫘아악~” 깔아왔던 것입니다.
전자서명이 필요 없는 서비스에 ‘보안접속’ 명목으로 이런 플러그인을 깔아대는 것은 컴맹 수준의 웹사이트 발주 고객(예를들어, 국내 각 대학교)을 속여서 돈을 뜯어 내는 행위입니다. 외국에서는 상상도 할 수 없는 일입니다. ‘보안접속’ 용도로는 도저히 누구에게도 팔 수 없는 프로그램을 ‘전문보안업체’라는 업자들은 국내의 컴맹 발주 고객들에게 그동안 계속 팔아왔으며, 웹사이트 발주자와 공무원들은 ‘보안접속’을 위해서는 어쩔 수 없나보다 하고 지난 10년간 속아왔던 것입니다.
이 사태는 전문보안업체가 ‘기술을 몰라서’라기 보다는, 마케팅 능력과잉과 양심불량이 빚어낸 결과일 것입니다. 몇몇 업체들이 시장을 장악하고 나눠먹기 하는 구도에서는 소비자(웹사이트 발주자)들은 이렇게 당하는 것입니다.
물론, 전자서명이 필요한 서비스(금융거래, 민원신청, 조달 계약 체결)는 조금 다른 고려가 필요합니다.
유럽의 여러 나라들(스웨덴, 덴마크, 노르웨이, 벨기에, 스페인, 포르투갈, 아이슬랜드 등)도 금융거래에 전자서명을 사용하며, 그 나라들도 전자정부 서비스에 전자서명을 사용합니다. 그러나 ‘보안접속’과 ‘전자서명’을 비빔밥처럼 하나로 (얼)버무린 프로그램을 사겠다는 웹서버는 아마도 한군데도 없을 것입니다. 그런 프로그램을 도입하는 순간, 자기 웹사이트를 방문, 이용하는 고객은 위에 설명한 것과 같이 ‘골탕 먹게’ 되기 때문이지요.
‘전자서명’과 ‘보안접속’을 하나의 플러그인으로 해치우려는 시도 그 자체가 ‘기술적 실패’라는 점을 이제는 인정하셔야 될 것입니다.
은행에서 원하기만 하면 법적인 제한없이 https를 SEED 대신 쓸 수 있다는거지요? 그럼 거래 은행에 민원을 제기하는 것으로 몇몇 은행의 보안접속을 바꾸는 정도는 가능할 것 같습니다.
금융권 웹사이트의 경우 1~4 번은 어차피 공인인증 플러그인의 설치로 플러그인 기반 페이지 암호화 까지 지원되는 것이므로 독립적인 문제는 아니라고 생각합니다. 공인인증이 플러그인을 제공되는 이상 1~4번 문제는 어차피 발생하는 것이니까요. (플러그인의 인스톨을 어떻게 할 것인가 등등의 문제는 생략..)
그리고 6번의 경우 플러그인 기반 암호화와 검색엔진의 색인하고는 별 관련성이 없습니다. 로그인이 필요하지 않은 페이지는 어차피 페이지 암호화가 적용안되는 평문으로 보이고, 로그인이 필요한 페이지는 검색엔진도 못 들어가니까요. (브라우저야 플러그인 안깔면 못들어가게 막지만 검색엔진은 그런거 신경 안쓰고 소스 까서 링크 있으면 그냥 들어갑니다)
일단 플러그인 체체 자체의 장/단점을 제외하고 생각하면 다음과 같습니다. 실무적인 입장에서는 플러그인 기반 페이지 암호화의 장점으로
1. 웹페이지의 일부만 암호화 할 수 있으므로 성능면에서 효율적이다.
2. 지금껏 잘 써오던 방식이고 국정원 인증도 받았고.. 딱히 바꿀 이유가 없다(…이건 장점이라고 하긴 뭐하군요 -_-)
단점으로는
1. 사용자가 (심지어 개발자 조차도-_-) 지금 보고 있는 내용이 암호화 되고 있는지 알 방법이 없다.
2. 위의 5번. 사이트 전체에서 즐겨 찾기가 안되고 뒤로 버튼이 정상적으로 작동하지 않는다.
저는 아무래도 단점이 크다.. 라는 생각이긴 한데 그게 압도적 단점이 크다.. 라고 하기엔 문제가 있네요. 특히 많은 분들에게 2번의 장점이 크게 어필하고 있는 상황입니다.
아직 1번의 장점이 얼마나 되는지 이론적으로만 알지 수치적으로 계산해본 적은 없는데요. 조만간 여유가 생기면 계산해 봐서 그 이득이 그리 크지 않다면 제가 담당하는 부분에서만이라도 SSL로의 전향을 추진해 보겠습니다. ^^
예, 저도 ‘전자서명’이 필요한 부분은 별도로 다루어야 한다고 생각합니다.
검색이 제대로 안된다는 문제는 ‘프레임’ 사용으로 인한 어려움을 지적했을 뿐, 플러그인 설치와는 상관 없습니다.(프레임에 관한 여러 설명들을 보니, 프레임은 검색로보트의 접근을 어렵게 만든다는 지적이 있습니다)
‘보안접속’과 관련하여,
“지금껏 잘써왔다”는 견해는 선뜻 납득하기 어렵네요. 사이트 운영자의 입장에서는, 무수한 설치오류 문의에 응대해야 하는데, 이것은 큰 부담입니다. 그리고 플러그인 업데이트, maintenance 등도 모두 비용이 드는 것이지요. https 였더라면 지출하지 않아도 될 비용이겠지요.
이용자(고객)입장에서는 “ActiveX OK”를 해야 한다는 것은 (적어도 외국에서는) 엄청난 부담이며, 사실상 금기시 되는 것입니다.(“반드시 ‘예’하라”는 국내 은행들의 거듭된 안내는 국가적인 보안 허약화를 초래합니다. 악성 프로그램 유포에 ‘최적화’된 컴퓨터 ‘이용습관’을 만들어 왔지요. 제가 보기에는 이것이 가장 치명적인 단점입니다.)
그리고, MS IE를 사용하지 않는 고객들은 “지금껏 못써왔습니다”
1번 장점(페이지 일부 암호화)은 CSS디자인을 제대로 구사하면, 장점이라 하기도 어렵지 않을까 생각합니다. 전세계의 금융권 웹사이트들이 모두 https 를 사용하는데, 우리만 이러구 있으니 참 딱하네요.
아무쪼록 신속한 개편이 이루어지면 정말 고맙겠습니다.
viz 님의 코멘트를 반영하여 게시글을 조금 수정하였습니다. 다시 한번 감사드립니다.
SEED의 사용과 관련해서 플러그인이라는 방식을 사용하게 된 배경이라고 생각해 볼 수 있는것이,, (제 주관적인 의견입니다.)
128bit 대칭키 암호화 알고리즘을 이용한 보안접속의 목적 이외에도,, 로컬PC에 인증서와 개인키가 저장되어 있고, 개인키를 암/복호화하는데 사용된 알고리즘이 SEED 였기 때문이라고 생각합니다.
전자서명을 하기 위해서는 개인키(주로 HDD에 저장된)를 풀어야하는데, 단순히 SEED 알고리즘의 구현이 아닌 PKCS#5라는 흐름안에 구현이 스며들어야 했지요..
최근에는 개인키뿐만 아니라 신원확인을 위한 식별정보가 개인키에 포함되어 있다보니,, 주민번호를 이용한 신원확인을 하는 경우에도 해당됩니다.
공인인증 인프라상에서 기밀성뿐만 아니라 이외에 인증, 무결성, 부인방지를 한꺼번에 제공하겠다는 요구사항에 대한 기술분야의 해답이 된 것이 플러그인이 아니었을런지요.
말씀하신 것처럼 ‘보안접속’ 즉 기밀성만 요구되는 서비스에는 https를 이용하는게 맞다고 생각합니다.
다른 요구사항(부인방지, 인증 등)도 같이 필요한 경우이면서 공인인증서를 이용한 법적 효력도 갖는 서비스라고 한다면 좀 다르게 접근해봐야 하겠지만요..
은행에서 원하기만 하면 법적인 제한없이 https를 SEED 대신 쓸 수 있다는거지요? 그럼 거래 은행에 민원을 제기하는 것으로 몇몇 은행의 보안접속을 바꾸는 정도는 가능할 것 같습니다.
현재 법으로 SEED 외에 보안 프로그램은 사용할 수 없습니다. IT후진국의 현실이죠.
근거가 없는 주장인듯하군요. 금융 보안 IT분야에 근무하시는 분들은 자신이 알지도 못하고, 존재하지도 않는 “법규정” 타령을 하기를 유난히 좋아하시는 듯하여 딱합니다.
앞으로 법규정이야기를 하시려면, 근거 규정 몇조, 몇항인지를 제시하시면 좋겠네요.
128bit is really secure. but lot consuming time for encrypting