WWW Security

박현동

대전 광역시 유성구 궁동 220

충남대학교 컴퓨터과학과 분산처리연구실

E-mail : hdpark@esperosun.chungnam.ac.kr

Abstract:

본 강의에서는 WWW이 가지고 있는 보안의 취약점들과 가능한 공격방법들, 그리고 이러한 문제점들을 해결해 주기 위해 발표 된 방법등 기초적인 내용을 알아본다.

Keywords:

WWW, 보안, 암호, 인증, 기밀성, 키

1. 서론

WWW은 처음 소개된 이래로 수년 동안에 엄청난 질적, 양적의 성장을 거두어 왔다. 이를 유도한 이유 중의 하나는 Netscape와 Mosaic 등 사용자들이 인터넷이나 WWW에 많은 지식을 가지고 있지 않아도 쉽게 사용할 수 있는 브라우저(Browser)의 개발에 있다고 해도 과언이 아니다. 또한, 기존의 서비스와는 구별되게 단순한 텍스트 형태의 서비스에서 벗어나 사운드, 그림, 동영상 등 컴퓨터에서 다룰 수 있는 거의 모든 형태의 자료를 지원해 준다는 점도 WWW의 발전에 큰 기여를 하고 있다. 이러한 성장은 곧 사용자층의 확대를 의미한다. 초기의 인터넷은 주로 연구용으로 사용되었기 때문에 전문가들만이 사용하였으나, WWW의 출현으로 인해 일반 시민들의 참여가 늘어났다. 일반 시민들의 참여는 곧 인터넷의 상업용 사용으로 이어지게 되었다.

하지만, 이러한 성장에도 불구하고 WWW의 안전 문제는 아직도 큰 문젯거리로 남아 있다. 클라이언트와 서버 사이의 상호 인증도 풀어야 할 과제이고, 인터넷을 이용해 전송되는 메시지의 내용에 대한 공격에 대해서도 대비가 필요하다. 이런 문제는 인터넷을 통해 막대한 많은 양의 경제활동이 이루어질 수년 뒤를 위해서 반드시 해결해야 할 과제이다.

세계적인 규모의 전자 상거래는 활동 중인 해커들에게는 매우 큰 매력으로 다가서고 있다. 전자 상거래에 대한 공격은 해커뿐만 아니라 범죄자, 불순한 의도의 직원, 심지어는 정부의 요원에 의해서까지 발생할 수 있다. 인터넷을 이용한 해킹은 약간의 기술을 습득함으로써 활동무대를 전세계로 넓힐 수 있고, 각자의 해킹기술을 손쉽게 공유함으로써 많은 해킹기술들이 전파되고 있다.

인터넷은 본래 태어나기를 연구용으로 태어났기 때문에 상업용 환경에는 적합하지 않은 것이 사실이다. 보안보다는 사용의 편리성과 공동작업의 효율성이 더욱 중시되었기 때문이다. 인터넷이 사용하고 있는 TCP/IP는 인증이나 기밀성을 위한 요소를 포함하고 있지 않다. 또한 응용계층 중의 하나인 FTP를 보더라도, 기본적인 사용자 이름과 패스워드 검사는 있지만, 많은 경우에 anonymous FTP를 위해서 프로그램이 수정되고 있다.

본 강의에서는 WWW이 가지고 있는 보안 취약점과 이 문제를 해결해 주기 위해 만들어진 보안 방법들을 알아본다.

2. WWW의 보안 취약점과 보안 요구사항

2.1 WWW의 보안 취약점

WWW은 기본적으로 보안에 취약한 성질을 가지고 있다. 그 이유는 HTTP의 하위계층인 TCP/IP에서 아무런 보안 기능을 제공해 주 지 않고 있기 때문이다. WWW이 가지고 있는 보안의 취약점을 생각하면 먼저 기밀성을 들 수 있다. WWW에서 통신되는 모든 HTTP 메시지들은 평문(Plaintext)으로 전송되기 때문에 의도적으로 이를 도청할 수 있다. WWW에서 제공하는 모든 내용이 공개되어도 문제가 없는 상황이면 괜찮겠지만 WWW이 전자상거래의 수단으로 사용되고 있는 시점에서는 기밀성의 지원여부가 매우 중요한 요소로 작용한다.

그 다음으로는 사용자 인증이다. 기본적인 HTTP에서는 클라이언트나 서버에 대해 사용자 인증을 수행하지 않는다. 클라이언트는 다른 사람의 이름으로 서버에 접속할 수 있으며, 서버 또한 클라이언트의 신원을 확인하지 못하고 서비스를 제공하게 된다. 이에 대한 부분적인 대비책이 HTTP에서 지원해 주고 있는데, 자세한 내용은 다음 장에서 보기로 한다.

메시지의 무결성도 지원해 주지 못한다. 클라이언트와 서버에서 전송하는 메시지들이 전송 도중에 불법적으로 변경될 수 있고, 이러한 사실을 클라이언트와 서버가 감지해 내지도 못한다.

이러한 기본적인 보안 취약점 이외에도 클라이언트 프로그램과 서버 프로그램에서 각각 가지고 있는 취약점들은 다음과 같다.

2.1.1 클라이언트의 보안 취약점

클라이언트 프로그램을 사용하면서 발생할 수 있는 보안 문제점 중의 하나가 external viewer의 보안 취약점이다. 브라우저 사용자는 external viewer를 사용하여 여러 가지 형태의 자료를 열람한다. 그러나, 누군가가 external viewer를 제작하여 그 안에 security hole를 심어 놓는다면 브라우저 사용자는 자신도 모르는 사이에 피해를 입을 수 있다. 이러한 상황을 방지하기 위해서는 external viewer를 설치할 때에 반드시 검증된 프로그램을 사용하도록 한다.

2.1.2 서버의 보안 취약점

WWW서버를 운영하자면 많은 수의 CGI(Common Gateway Interface)프로그램을 수행하게 되는 것이 보편적이다. 하지만, CGI 프로그램은 클라이언트의 요청에 의해 서버에 위치한 프로그램이 수행되는 것이기 때문에 이것이 보안에 있어서 큰 취약점으로 작용할 수 있다. 서버 관리자는 httpd를 루트의 권한으로 수행시키지 않도록 하며 CGI프로그램이 접근할 수 있는 디렉토리를 확실히 지정해야 한다. 그리고, CGI프로그램을 설치할 때에는 반드시 검증된 프로그램만을 사용하는 것도 중요하다.

2.2 WWW의 보안 요구사항

WWW에서 보장되어야 할 보안 요구사항들을 살펴보면 다음과 같다.

2.2.1 HTTP(HyperText Transfer Protocol) 트랜잭션(Transaction)의 기밀성 (Confidentiality)

WWW의 통신에서 클라이언트 사용자와 서버만이 통신되는 내용을 파악할 수 있도록 하는 기능을 의미한다. 클라이언트와 서버 사 이의 통신 내용을 제3자가 중간에서 가로챈다 하더라도 그 내용을 알아 볼 수 없게 해야 한다. 이를 위해서 HTTP 메시지를 암호화하는 방법이 필요하다. 클라이언트의 request 메시지와 서버의 response 메시지에 포함되는 HTTP헤더(Header)들과 본문의 내용을 암호화한 후에 수신자를 지정해 주는 기본적인 헤더만을 암호문에 붙여 주는 방법이 필요하다.

2.2.2 서버와 클라이언트에 대한 인증(Authentication)

HTTP 트랜잭션이 발생하기 이전에 클라이언트는 서버를, 서버는 클라이언트의 신원을 확인해 줄 수 있게 하는 기능이다. 상대방에 대한 인증을 상호 가능케 함으로써 서버는 적합한 클라이언트 사용자에게만 문서를 볼 수 있게 하고 클라이언트는 위장된 서버로부터 엉뚱한 문서를 전달받는 상황을 방지할 수 있다. 이는 어느 특정한 메시지에 각자의 비밀키를 이용한 전자서명(Digital Signature)을 붙여 줌으로써 구현이 가능하다.

2.2.3 HTTP 트랜잭션의 무결성(Integrity)

서버는 클라이언트의 request 메시지가 전송 도중에 불법적인 변경이 없이 제대로 도착했을 가를 확인할 수 있어야 하고, 반대로 클라이언트는 서버가 보내 준 response 메시지가 전송 도중에 불법적인 변경이 없이 제대로 도착했을 지의 여부를 확인할 수 있어야 한다. 이는 request 메시지나 response 메시지를 전송 할 때에 이들 메시지의 해쉬함수(Hash Function)값을 함께 보냄으로써 수신자가 메시지를 받아 다시 계산한 해쉬값과 송신자가 계산해 보내 준 해쉬값을 서로 비교함으로써 구현할 수 있다. 두 값이 서로 일치하면 전송 도중에 아무런 문제가 발생하지 않았다는 의미가 되고, 서로 일치하지 않는다는 것은 메시지가 전송 도중에 어떤 형태로든지 변경되었다는 것을 의미한다.

3. WWW 보안 프로토콜

3.1 기존의 프로토콜

HTTP 1.0에서 부터 지원해 주고 있는 보안 기능은 앞 절에서 본 요구사항들 중 메시지의 기밀성과 무결성은 지원해 주지 못하고 있다. 클라이언트에 대한 인증은 어느 정도는 지원해 주고 있으나, 이 방법들도 각각의 약점이 있어 좋은 방법이라 할 수는 없다. 대개의 브라우저 사용자들은 신원을 밝히지 않은 상태로 서버에 접근하여 문서들을 열람할 수 있고, 서버의 신원을 확인해 줄 수 있는 확 실한 방법이 없어서 클라이언트들은 의도하지 않은 다른 서버에서 페이지를 전송해 주어도 이를 확인할 방법이 없다. 결과적으로 서버 쪽에서는 적절한 접근 제어를 구현하기가 쉽지 않고, 메시지는 평문의 형태로 전송되기 때문에 기밀성이나 무결성도 기대할 수 없다. 보안 요구사항들 중에서 접근제어를 위해 제공되고 있는 방법들을 보면 다음과 같다.

3.1.1 사용자ID와 패스워드를 이용한 Basic Authentication

HTTP 1.0버전부터 제공되어진 클라이언트 인증방법이다. HTTP에서 지원하기 때문에 HTTP를 사용하는 모든 브라우저와 서버 사이에서 이용할 수 있다. 이 방법을 사용하기 위해서는 몇개의 파일을 작성해 주어야 한다. 필요한 파일들은 .htaccess, .htpasswd, .htgroup이다. 각 파일들의 내용을 보면, .htaccess는 접근제어를 요구하는 디렉토리마다 하 나씩 존재한다. 이 파일에는 해당 디렉토리에 접근을 허용하는 사용자ID의 리스트, .htpasswd파일의 위치 등을 명시해 준다. 내용을 보면 다음과 같다.

AuthUserFile /otherdir/.htpasswd

AuthGroupFile /dev/null

AuthName ByPassword

AuthType Basic

<Limit GET>

require user hdpark tgkim

</Limit>

의미를 보면, 제일 윗줄의 AuthUserFile에는 사용자들의 패스워드를 저장하고 있는 파일의 패스(path)를 지정해 준다. .htpasswd에는 각 사용자들의 등록된 로긴네임(Login name)과 암호화된 패스워드가 저장되어 있다. 접근이 허용된 사용자들의 수가 클 경 우, 관리의 효율성을 위해 .htgroup파일을 만들어 이곳에 모든 사용자 ID를 저장하고, .htaccess파일에는 .htgroup파일이 있는 곳의 패스를 지정해 준다. 사용자ID를 모두 저장하고 있는 파일을 지정해 준 곳이 두 번째 줄의 AuthGroupFile이다. AuthName의 ByPassword는 접근제어 방식으로 패스워드를 사용하고 있다는 것을 나타낸다. AuthType은 이 방법이 Basic Authentication이라는 것을 나타낸다. <Limit GET>은 이 접근제어 방식은 GET method를 가진 request 메시지에 해당한다는 것을 나타낸다. Require user는 패스워드 검사를 통해 접근이 허용되는 사용자들의 ID리스트를 지정해 놓는다. 위의 예에서는 hdpark과 tgkim이 접근 이 허용되고 있다. Hdpark과 tgkim은 올바른 패스워드를 입력함으로써 해당 디렉토리에 있는 자료들에 대한 열람이 허용된다.

하지만, 이 방법이 완벽한 접근제어를 구현해 준 것은 아니다. 클라이언트가 입력한 패스워드는 암호화되지 않고 단지 uuencode 된 형태로 서버에까지 전송되기 때문에 도중에 네트워크 상에서 패스워드가 노출될 수 있다. 패스워드가 노출되면 접근권한이 없는 사람이 그 패스워드를 사용하여 적합한 사용자인 것처럼 가장하여 서버에 접근할 수 있다. 또한 등록되어 있는 사용자의 수가 너무 크거나, 이들의 패스워드를 자주 변경해 주어야 할 경우에는 서버 관리자에게 너무 큰 오버헤드(Overhead)가 주어지는 문제점이 발생한다.

3.1.2 네트워크 주소를 이용한 접근제어

사용자 인증을 위해서 HTTP에서 제공하는 또 하나의 방법으로 클라이언트의 네트워크 주소를 이용한 IP(Internet Protocol) filtering 방법이 있다. 이 방법을 사용하기 위해서는 .htaccess 파일에 사용자ID가 아닌 클라이언트의 주소를 지정해 줌으로써 접근을 허용하거나 거부할 수 있다. 만약, .chungnam.ac.kr이라는 도메인에서 오는 request 메시지를 허용하려면 .htaccess파일에 allow from chungnam.ac.kr이라고 지정해 주고, 거부할 경우에는 allow 대신에 deny를 사용한다.

AuthUserFile /dev/null

AuthGroupFile /dev/null

AuthName ExampleAllowFromChungNam

AuthType Basic

<Limit GET>

order deny allow

deny from all

allow from .chungnam.ac.kr

</Limit>

사용자의 ID나 패스워드를 필요로 하지 않기 때문에 AuthUserFile과 AuthGroupFile에는 아무런 패스도 지정되지 않았다. Deny from all과 Allow from .chungnam.ac.kr에서 chungnam.ac.kr에서 오는 request 메시지만을 허용하고 그 이외의 다른 곳에서 오는 request 메시지는 거부한다는 것을 알 수 있다.

이 방법은 사용자 ID와 패스워드가 네트워크를 통해 전송되지 않아도 된다는 점에서 더욱 간단하고 안전하다고 볼 수도 있다. 하지만, 대개의 해커가 자신의 IP주소를 변조할 수 있다는 점을 감안할 때에는 안전하다고는 할 수 없는 방법이다. 또한 이 방법은 접근제어가 브라우저 프로그램이 수행되는 컴퓨터 단위로 구현되었기 때문에 진정한 사용자별 접근제어는 기대할 수 없다.

3.1.3 패스워드 검사와 네트워크 주소를 병합한 접근 제어

접근제어를 하는 대부분의 서버는 패스워드를 검사하는 방법과 네트 워크 주소로 접근을 제어하는 두 가지 방법을 혼합하여 사용하고 있다. 『chungnam.ac.kr에서 오는 request 메시지들 중에서 hdpark과 tgkim에 대해서만 패스워드를 검사하여 접근을 허락하고, 그 이외의 도메인이나 chungnam.ac.kr에 있는 사람일지라도 hdpark과 tgkim 이외의 사람들에게는 접근을 허용하지 않는다.』 라는 의미를 표현하는 .htaccess파일의 구성은 다음과 같다.

AuthUserFile /otherdir/.htpasswd

AuthGroupFile /dev/null

AuthName ExampleAllowFromChungNam

AuthType Basic

<Limit GET>

order deny allow

deny from all

allow from .chungnam.ac.kr

require user hdpark tgkim

</Limit>

두 가지 방법을 혼합하여 좀 더 안전한 인증을 꾀하고 있지만, 패스워드가 평문으로 전송된다는 약점과 IP주소가 변경될 수 있다는 약점을 근본적으로 고치지 못한 방법이기 때문에 좋은 해결책은 될 수가 없다. 확실한 사용자 인증과 접근제어를 구현하기 위해서는 공개키 암호 알고리즘의 전자서명에 의한 사용자 인증 등이 사용되는 새로운 방법이 필요하다.

3.1.3 Log 파일

서버 프로그램에는 logs라는 디렉토리가 존재하는 데, 그 밑에는 access.log와 error.log라는 파일이 존재한다. access.log에는 서버에 접근(access)하여 성공한 request 메시지가 기록되고 error.log에는 접근에 실패한 request 메시지가 기록된다. access.log 에 기록된 내용을 보면 다음과 같다.

<ngrims.kepcorc.re.kr--[08/Nov/1995:14:41:53 +0900] GET /security/title.html HTTP/1.0 200 325>

이 기록에 의하면, ngrims.kepcorc.re.kr이라는 호스트에서 1995년 11월 8일 오후 2시 41분에 서버에 접근하여, security/title .html파일을 열람했다는 것을 알 수 있다. Error_log에 남는 기록의 내용은 다음과 같다.

<[Wed Nov 8 14:37:09 1995] httpd: access to /home/user/www/httpd/htdocs/auth3/tip.html failed for 168.188.66.84, reason: client denied by server configuration>

이 기록은 1995년 11월 8일 오후 2시 37분에 누군가가 /home/user/www/httpd/ htdocs/auth3/tip.html문서에 접근하려다가 서버가 요구하는 configuration에 맞지 않아서 접근이 거부되었던 것을 알 수 있다.

Access.log와 error.log를 사용하여 서버의 이용상태 정보를 알 수 있고, 만약 서버에 문제가 발생했을 경우에, 이 log 화일들 을 통하여 침입에 대한 증거를 확보할 수도 있다. 하지만, 이 파일들이 불법침입과 같은 사고를 미리 방지해 줄 수는 없고, 또한 위의 형태와 같은 자료들이 파일에 계속 누적되어 쌓이므로 나중에 문제가 발생하여 파일들을 조사할 때에 조사자에게 편리한 인터페이스를 제공해 주지 못한다. 또한, 접근이 빈번하게 일어나는 서버의 경우에는 이 파일들의 크기가 매우 빠르게 커지기 때문에 이 파일들의 관리 자체가 큰 문제점으로 남게 된다.

3.1.4 메시지 다이제스트 인증

이 방법은 HTTP에서 기본적으로 지원해 주는 방법은 아니다. 하지만 특허 관계로 사용이 자유롭지 못한 암호 알고리즘 대신에 특허 문제가 없는 해쉬 알고리즘을 사용하고 있다. 사용이 자유로운 알고리즘들을 이용한 방법 중에서는 가장 효과적인 사용자 인증 기술로 인정받고 있다. 이 방법은 HTTP 1.1 규격 이상에서 정의되어 있다.

Basic authentication 방법에서 패스워드가 평문으로 전송되는 것을 개선한 방법으로 사용자의 인증이 필요한 경우, 브라우저 사용자는 사용자ID와 패스워드, 그리고 replay 공격을 방지할 수 있는 타임스탬프(timestamp)를 작성한 후, 이를 해쉬함수를 이 용하여 특정한 길이의 비트로 표현한다. 여기에 사용자ID와 타임스탬프를 다시 붙여서 서버에게 보낸다. 해쉬함수는 일방향 함수이므로, 누군가가 도청한다 하더라도 본래의 패스워드를 추출할 수 없다. 서버는 request 메시지를 받은 후, 사용자ID를 보고 패스워드화일에서 패스워드를 찾아내 클라이언트가 했던 것처럼 사용자ID, 패스워드, 타임스탬프를 해쉬함수에 적용시킨다. 이 결과값과 request 메시지에 있던 값을 비교하여 사용자 인증을 수행한다.

ftp://ftp.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-http-digest-aa-02.txt

http://www.w3.org/pub/WWW/Protocols/HTTP/digest_specification.html

3.2 암호 알고리즘을 이용한 WWW 보안

인터넷에는 많은 연구 자료들이 저장되어 있는 데, 이들 중에는 대외비의 성격을 지닌 것들도 상 당 수에 달한다. 어느 특정한 집단 안에서만 정보를 공유하고 그 외의 사용자들에게는 열람을 허락지 않는 정보들의 관리 방법이 필요하게 되었다. 이는 곧 WWW서버로 전송되는 request 메시지들 중에서 사용자 인증을 거친 request 메시지에게만 문서를 보여 줄 수 있는 확실한 사용자 인증 방법을 요구하게 된 것이다. 또한 사용자의 신원을 확인하고, 그 사용자에게 문서를 전송해 줄 때에도 문서의 기밀성을 보장해 주기 위해 HTTP의 암호화가 필요하게 되었다. 보안성이 취약한 WWW을 안전한 시스템으로 만들기 위한 현재까지의 연구 상황을 살펴보면 다음과 같다.

3.2.1 SHTTP(Secure HTTP)

1994년에 EIT사의 Schiffman과 Rescorla 는 HTTP에 보안기능을 추가한 SHTTP를 발표하였다. SHTTP는 HTTP의 기능은 그대로 보존하면서 통신의 기밀성, 무결성, 송신부인 방지, 송신자 인증 등의 기능을 모두 제공해 주고 있다. 다양한 암호 알고리즘의 사용을 위해서 알고리즘과 동작 모드를 협상하는 절차가 포함되어 있다. 이는 각 서버와 클라이언트들이 자신들이 사용할 수 있는 알고리즘의 수준과 요구하는 보안 등급에 따라서 다양한 알고리즘을 사용하기 위해서이다.

HTTP메시지는 요구되는 보안 등급에 따라 암호화와 전자서명이 적용되고, PKCS-7이나 MOSS형식에 따라 캡슐화되어 SHTTP메시지로 구성된다. 이에 SHTTP헤더 정보가 추가되어 전달된다. 결국, HTTP메시지가 암호화되고 전자서명이 추가되어 보안을 지원하지 않는 기존의 TCP/IP 망을 통해 전송된다는 것이다. 이러한 방식을 메시지 기반 보안(Message-based security)방식이라고 한다.

http://www.commerce.net/information/standards/drafts/shttp.txt

http://www.terisa.com/shttp/current.txt

3.2.2 SSL(Secure Socket Layer)

SSL은 Netscape사에서 개발한 프로토콜로써 WWW만을 위한 프로토콜이 아니고 일반적인 인터넷 보안을 위한 프로토콜이다. 이는 TCP/IP 계층 밑에서 보안을 적용시키기 때문에 가능한 것이다. SSL에서는 통신내용의 기밀성, 클라이언트와 서버 인증 기능, 메시지 무결성, 협상절차 등을 지원해 주고 있다.

통신절차를 보면 통신하고자 하는 당사자 사이에 공개키 암호화 기술을 이용한 socket 루틴을 사용하여 안전한 통신채널을 설정하고, 이 채널을 이용하여 정보를 교환할 수 있도록 한다. WWW클라이언트와 서버 사이에는 정규의 HTTP프로토콜에 의한 접속이 이루어지며, 이 HTTP메시지는 통신망을 지나갈 때 하위 SSL 계층의 암호 통신에 의해 보호된다. 이러한 방식을 채널기반 보안(Channel-based security)방식이라고 한다.

미국 이외의 나라에서 SSL을 사용할 때에는 40비트 크기의 키를 사용하도록 되어 있다. 이는 미국의 법적 문제로 암호 알고리즘을 외국으로 수출할 때 알고리즘의 보안도를 낮추기 위한 방법이다. 물론, 미국 내에서는 128비트의 키를 사용한다. 그런데, 미 국 이외의 나라에서 사용하는 40비트의 SSL이 이미 해독되었다는 보고가 있었다. 그 상황은 다음과 같다.

SSL에서는 관용암호 알고리즘으로 RC4를 사용한다. RC4는 128비트의 키를 사용하고, 소스는 공개되어 있지 않다. 미국 이외의 나라에서 사용하도록 되어 있는 SSL에서도 RC4의 키로 128비트를 모두 사용한다. 하지만, 이 128비트 중에서 40비트만 암호화하여 전송하고, 나머지 88비트는 평문의 형태로 전송한다. 그래서 40비트의 키를 사용한다고 되어 있다. RC4의 소스가 비공개로 되어 있지만, 리버스 엔지니어링(Reverse engineering)기법을 사용하여 RC4의 소스를 도출해 내었다. 도출된 소스를 이용하여 암호화되었던 40비트 부분의 키를 해독하여 결과적으로 128비트의 모든 키가 노출된 셈이 되었다.

http://home.metscape.com/newsref/std/SSL.html

http://home.netscape.com/newsref/std/sslref.html

ftp://ftp.psy.uq.oz.au/pub/Crypto/SSL/

3.2.3 PGP등을 이용한 방법

PGP(Pretty Good Privacy)나 PEM(Privacy Enhanced Mail)과 같은 외부 응용 프로그램을 이용하여 메시지를 암호화한 후, 이 암호화된 문서를 HTTP를 통해 전송시킴으로써 통신의 보안을 보장하는 방식이다. 이 기술은 기존 의 HTTP, HTML, 서버프로그램, 브라우저 프로그램에 다른 보안 프로토콜에 비해 최소한의 수정을 요구하고 있어서 성공할 수 있는 방법으로 보인다.

이 방법에서 보안에 관련한 동작은 WWW시스템의 외부에 위치하는 암호모듈(PGP, PEM,..)을 사용한다. PGP는 HTTP 메시지를 하나 의 파일로 간주하여 전자서명과 암호화 작업을 수행한다. 암호화된 HTTP메시지는 기본적인 HTTP 헤더가 추가된 후, HTTP을 따라서 전송된다. 암호화/복호화 작업등은 서버에서는 CGI 프로그램에서 수행한다. 그러나, 클라이언트에서는 사용하는 브라우저에 따라서 방법이 변하게 된다. 만약, Mosaic을 사용한다면, NCSA의 CCI(Common Client Interface)를 사용해야 하고, Netscape를 사용한다면, Plug-in이나 Client API기법을 이용해야 한다. 이러한 방식을 내용기반보안(Message-based security) 방식이라고 한다.

http://sdg.ncsa.uiuc.edu/~jweeks/www4/paper/current_rev.html

4. 결론

"완벽한 보안 시스템은 없다." 조금은 지나치게 들릴 수도 있지만 사실이다. 아무리 좋은 유틸리티들과 강력한 암호 알고리즘을 사용한다 하더라도 그것은 그 당시의 기술적 환경에 의존한 것이지 완벽한 것은 아니다. 지금 매우 강력하다는 암호 알고리즘도 불과 몇 년, 몇 개월 사이에 해독이 될 수 있다. 또한, 강력한 접근제어를 위해 사용하는 유틸리티들도 어디에 허점이 있는 지는 알 수 없다. 우리가 안전하다고 말할 수 있는 이유는 존재하는 허점이 아직 발견되지 않았기 때문이다. 어떤 보안 시스템을 장착했다고 해서 그것을 맹신해 서는 안된다. 언제나 주의가 필요하다.

그러나, 무엇보다도 중요한 것은 사용자 한명 한명이 보안에 대한 의식을 가지는 것이다. 보안을 적용시키면 현재 우리가 사용하는 환경보다 귀찮아지는 것은 사실이다. 이러한 이유로 사용자들이 보안 개념을 등한시한다. 또한, 피해가 당장 눈에 보이지 않는다는 것도 등한시하게 되는 이유 중의 하나이다. 하지만, 보안 사고의 피해는 눈에 보이지 않게 서서히 쌓여져 간다.

우리가 앞으로 인터넷을 무시하고 삶을 살아갈 것이 아니라면, WWW 보안은 반드시 보장되어야 할 점이다. 여러분이 백화점에 접속하여 상품을 구매했을 때, 대금을 지불하기 위해 사용한 정보가 다른 사람의 손에 들어가 여러분의 돈을 다른 사람이 물 쓰듯이 펑펑 쓰고 있는 모습을 상상해 보면 실감이 날 것이다.