RFC 3875: CGI의 서버 측 TLS 경계

요약

CGI/1.1은 HTTP 서버와 스크립트 사이의 공통 요청·응답 전달 절차를 기술했으며, 일부 세부 사항은 시스템 또는 구현에 따라 정의되도록 남겨 두었다.
RFC 3875는 TLS를 클라이언트와 서버 사이에 두었다. 클라이언트를 향해 서버가 인증되지만, 스크립트에는 자신을 호출한 주체에 대한 내장 증명도, 무결성이 보호된 CGI 메시지도 제공되지 않았다.

연결은 안전하다. 그 연결의 반대쪽 끝에 있는 애플리케이션이 반드시 안전한 것은 아니다.

이 구분이 2004년 Common Gateway Interface(CGI) 버전 1.1 명세인 RFC 3875 속 조용한 경계다. 브라우저는 웹 서버와 TLS 세션을 맺을 수 있다. 서버는 그다음 요청 데이터를 CGI 프로그램에 전달할 수 있다. 그러나 RFC가 기술하는 보안 관계는 그 두 번째 전달 지점을 온전히 건너가지 않는다. 서버가 네트워크 피어이고, 스크립트는 그 뒤에 있는 애플리케이션 프로세스다.

CGI는 RFC 3875가 등장하기 훨씬 전부터 실질적인 역할을 해 왔다. HTTP 서버는 데이터베이스나 기존 정보 시스템에 대한 게이트웨이 역할을 할 수 있었고, 스크립트가 요청으로부터 응답을 만들어 냈다. W3C의 역사적 CGI 페이지는 이 인터페이스를 게이트웨이 스크립트와 프로그램을 통합하기 위한 서버 구현자들 사이의 합의라고 부른다. 같은 페이지는 1995년의 CGI 1.1 갱신 시도와, 1997년 11월에 다시 활성화되어 사실상의 인터페이스를 Informational RFC로 만들려던 작업을 기록하고 있다. 최종 RFC는 2004년 10월 독립 제출 스트림(Independent Submission Stream)을 통해 발행되었다.

이 긴 간격은 표준 절차의 흥미로운 사례라기보다, 그 문서가 담으려 했던 것이 무엇인지를 보여주는 증거로 의미가 있다. CGI는 이미 실용적인 관행이었다. RFC 3875는 동적 웹 애플리케이션을 발명하지 않았다. 네트워크를 향한 서버에서 애플리케이션 프로그램으로 넘어가야 하는 요청을 둘러싼 이식 가능한 계약을 문서로 적은 것이다.

이 계약은REQUEST_METHOD,QUERY_STRING,CONTENT_LENGTH,PATH_INFO,REMOTE_ADDR같은 요청 "메타 변수"를 명명한다. 문서 응답과 리디렉션 응답을 포함해 스크립트가 헤더와 본문을 돌려주는 방식도 정의한다. 이 덕분에 서로 다른 서버를 위해 작성된 프로그램들이 공통 어휘를 공유할 수 있었다. 책임의 위치도 밝혀져 있다. 서버는 클라이언트 연결, 데이터 전송, 네트워크 프로토콜을 관리하고, 스크립트는 데이터 접근이나 문서 처리 같은 애플리케이션 작업을 수행한다.

이 분담은 서버의 의무를 넘겨주는 것이 아니다. RFC 3875는 스크립트가 명세를 준수하지 못하더라도 서버는 네트워크 프로토콜 준수에 대해 클라이언트에 대해 책임을 유지한다고 명시한다. 또한 인증을 수행하는 서버는 정의된 접근 통제를 요청이 통과하기 전까지 스크립트를 실행해서는 안 된다고 요구한다. 서버는 나쁜 응답이나 건너뛴 게이트를 자식 프로세스 탓으로 돌릴 수 있는 투명한 파이프가 아니다.

그다음 9.4절이 신뢰 경계를 좁힌다. TLS 클라이언트 연결에 대해 보안 모델은 클라이언트와 서버 사이에 적용되며, 클라이언트와 스크립트 사이에는 적용되지 않는다. 서버는 클라이언트에 대해 인증된다. 명세는 스크립트에 자신을 호출한 서버를 인증할 메커니즘을 제공하지 않으며, CGI 요청·응답 메시지에 무결성을 강제하지도 않는다.

이것은 스크립트가 반드시 신뢰할 수 없다는 주장도, 운영자가 로컬 프로세스 경계를 보호할 수 없다는 주장도 아니다. 서버는 운영체제 권한, 사적 채널, 기타 로컬 통제를 사용할 수 있다. 더 좁은 요점은 HTTP 가장자리의 TLS가 그 자체로는 다운스트림 스크립트를 동일한 엔드포인트로 인증하지 않는다는 것이다.HTTPS=on이나 사용자 이름을 환경에서 받은 스크립트는 값을 받은 것일 뿐이며, CGI 인터페이스는 그 값들을 인증된 클라이언트 세션에 결합하는 암호학적 증명을 제공하지 않았다.

이 아키텍처는 의도적으로 하나의 프로세스 모델보다 넓었다. RFC 3875는 서버의 사용자·그룹 아래에서 실행되는 자식 프로세스를 가장 흔한 구현으로 기술하면서도, 서버에 링크된 스크립트도 인정한다. 시스템에 따라 달라질 수 있는 동작은 "시스템 정의(system-defined)", 구현에 따라 달라질 수 있는 동작은 "구현 정의(implementation-defined)"로 표시한다. 공통 인터페이스는 어느 한 서버의 실행 기계보다 더 멀리 갈 수 있었지만, 그 이식성에도 한계가 있었다.

Apache의mod_cgi문서는 유용한 구현 예시이지 웹 전체의 조사 결과는 아니다. 이 문서는 한 서버 계열이 핸들러나ScriptAlias로 스크립트를 선택하고 그 출력을 클라이언트에 돌려주는 모습을 보여준다. 그 기계장치는 전달 지점을 설명해 줄 뿐이며, TLS가 어디서 종료되는지에 대한 RFC의 주장을 바꾸거나 모든 서버의 구성 방식을 확립하지는 않는다.

CGI의 역사적 성과는 공유된 프로세스나 종단 간 보안 채널이 아니라 공유된 경계였다. 서버와 스크립트는 명명된 인터페이스를 통해 협력하면서도, 서로 다른 책임을 지닌 별개의 주체로 남았다. RFC를 이렇게 읽으면 흔한 범주 오류를 피할 수 있다. 브라우저에서 서버까지 보호된 요청이 곧 브라우저에서 애플리케이션까지 보호된 관계인 것은 아니다. RFC 3875는 이 분리를 명시적으로 만들었을 뿐, 그것을 지우지는 않았다.