요약

  • RFC 2384는 POP3 호스트, 포트, 메일함 식별 정보와 인증 방식 선택을 하나의 URL에 담았지만, 평문 비밀번호를 문자열에 넣는 것은 의도적으로 배제했다.
  • 그러나 이 URL은 저장된 비밀 정보를 사용할 권한이 아니었다. 클라이언트는 신뢰할 수 있는 출처, 로컬 정책, 사용자 확인, 서버 검증, 또는 재사용 가능한 정보를 노출하지 않는 인증 방식 중 하나를 갖춰야 했다.

편리한 문자열

RFC 2384의 매력은 평범한 설정 문제에서 시작된다. 메일 프로그램에는 메일함 이름 이상이 필요했다. 서버, 기본값이 아닌 포트, 식별 정보, 그리고 인증에 관한 어떤 결정이 필요했다. 이 요소들은 환경설정 패널 곳곳에 흩어지기 쉽고 프로그램 간에 옮기기 어려웠다. 이 RFC의 답은 일반적인 형태가pop://<user>;auth=<auth>@<host>:<port>인 URL이었다.

이 압축된 형식은 실제로 유용했다. 호스트가 유일하게 없어서는 안 될 요소였다. 포트는 POP3 기본값인 110으로 사라질 수 있었다. 식별 정보와 인증 메커니즘은 있을 수도, 없을 수도 있었다. URL 문자 레퍼토리에 맞지 않는 문자는 인코딩될 수 있었다. 프로그램은 하나의 문자열을 받아 파싱하고, POP3 세션을 시작하기에 충분한 정보를 얻을 수 있었다.

중요한 단어는시작이다. 이 URL은 메일함으로 들어가는 제안된 경로를 서술했다. 그 경로가 신뢰할 수 있는 출처에서 왔는지, 명명된 호스트가 자격 증명을 받을 자격이 있는지, 서버가 의도된 서버인지, 선택된 메커니즘이 안전한지, 인증과 메일함 접근이 성공할지는 증명하지 않았다. RFC 2384의 가장 오래 지속되는 기여는pop스킴 자체가 아니다. 바로 서로 다른 사실들을 문자열의 겉보기 완결성 안으로 하나로 묶어버리기를 거부한 점이다.

비밀번호는 없었지만 위험은 있었다

RFC 2384는 URL 안에 평문 비밀번호를 허용하지 않았다. 이것은 유용한 최소 규칙이었다. URL은 문서, 설정 저장소, 리퍼러, 로그, 인터페이스를 통해 이동한다. 참조 안에 비밀번호를 직접 넣는 것은 비밀 정보의 노출 면적을 넓혔을 것이다.

그러나 문자열에서 비밀번호를 삭제하는 것이 자격 증명 결정을 삭제하지는 않았다. 클라이언트는 이전 로그인에서 이미 비밀번호를 갖고 있을 수 있다. URL을 연 뒤 사용자에게 물어볼 수 있다. APOP을 사용하거나 SASL 메커니즘과 함께 POP3AUTH명령을 호출할 수 있다. 따라서 URL은 비밀 정보를 담지 않으면서도 비밀 정보가 이동하도록 만들 수 있었다.

문서는 이 구분을 직접 다뤘다. URL은 신뢰할 수 없는 출처에서 쉽게 올 수 있고, 잘못된 서버로 보내진 자격 증명은 계정을 위태롭게 할 수 있다고 경고했다. 보안 섹션은 더 나아갔다: 평문 비밀번호를 저장하는 클라이언트는, 지정된 호스트명에 그 비밀번호를 제공할 명시적 허가 없이는 POP URL에 응답하여 그 비밀번호를 사용할 수 없다.

이것은 "링크에 비밀 정보를 넣지 마라"보다 날카로운 규칙이다. 통제 질문은 링크가 무엇을 담는지만이 아니다. 링크를 받았기 때문에 소프트웨어가 어떤 행동을 하는지가 문제다.

식별과 권한은 서로 다른 필드였다

URL은 RFC가 부른 사용자 이름을 담을 수 있었지만, 문서는 그 편리한 라벨 아래 두 개념이 압축되어 있다고 짚었다. 인가 식별(authorization identity)은 어떤 메일함에 접근할지를 답한다. 인증 식별(authentication identity)은 누구의 자격 증명을 검증할지를 답한다. 둘은 같은 문자열일 수 있지만 같은 기능이 아니었다.

같은 구분이 인증 메커니즘에도 적용됐다. URL은 SASL 메커니즘, APOP 또는 다른 확장을 지명할 수 있었다. 특정 메커니즘을 지명했을 때 클라이언트는 명시적인 사용자 허가 없이 조용히 다른 메커니즘을 선택해서는 안 된다. 문자열은 제안을 제약했을 뿐, 보이지 않는 대체를 허가하지 않았다.

와일드카드 형식;AUTH=*은 위험을 더 선명하게 만들었다. 이것은 클라이언트에게 적절한 메커니즘을 선택하라고 지시하고, 서버가 지원하는 모든 메커니즘을 허용했다. 더 미묘하게는, 사용자 이름을 제공하면서 메커니즘을 생략한 URL은 암묵적으로 그 와일드카드를 의미했다. 겉보기에 단순한 주소가 따라서 협상 지점을 열 수 있었다. 서버가 광고하거나 수용하는 선택지, 클라이언트의 선호 순서와 폴백 동작이 강한 메커니즘이 강하게 유지될지, 약한 메커니즘이 편리해질지를 결정할 수 있었다.

RFC 2384는 클라이언트에게 와일드카드를 각별히 조심하라고 했다. 약한 메커니즘으로 폴백할 수 있기 때문이다. 56비트보다 강한 암호화에 대한 언급은 1998년의 것이며 현대의 안전 기준이 아니다. 구조적 경고는 여전히 유효하다: 지정되지 않은 선택도 여전히 선택이고, 폴백도 여전히 정책이다.

자격 증명 경계를 넘는 다섯 가지 방법

RFC 2384는 URL 문법이 신뢰를 해결할 수 있다고 가장하는 대신, 국소화된 결정 지점을 남겼다. URL이 요청한 인증을 사용하기 전에, 파싱하는 프로그램은 다섯 조건 중 최소 하나를 충족해야 했다.

URL은 클라이언트가 이미 검증하고 사이트 정책 아래 신뢰한 리퍼러 출처에서 왔을 수 있다. 명시적인 로컬 정책이 명명된 서버로의 접속을 허용할 수 있다. 예컨대 알려진 도메인 내에서 그럴 수 있다. 사용자가 자격 증명 또는 메커니즘과 함께 정확한 도메인을 확인할 수 있다. 인증 메커니즘이 클라이언트의 위험한 정보를 드러내기 전에 서버를 검증할 수 있다. 또는 메커니즘이 수신자가 미래의 접속을 위태롭게 하는 데 재사용할 수 있는 정보를 아무것도 드러내지 않을 수 있다.

이 다섯 가지는 동일한 신뢰 주장의 다섯 가지 표현이 아니었다. 각각은 권한을 서로 다른 행위자와 증거에 부여했다. 검증된 리퍼러는 신뢰를 출처에 붙였다. 로컬 정책은 행정 규칙에 붙였다. 확인은 특정 목적지에 대한 사람의 결정에 붙였다. 서버 검증은 인증 교환에 붙였다. 비공개 방식은 잘못된 상대와 접속했을 때의 결과를 바꿨다.

URL 작성자는 제안된 목적지를 통제했다. 그 어떤 조건도 그 작성자에게 자격 증명에 대한 통제를 자동으로 주지 않았다.

상대 URL이 금지된 이유

RFC 2384는 상대 POP URL을 허용하지 않았다. POP 메일함 참조는 문서 속 주변 기준 주소에서 호스트를 빌려올 수 없었다. 목적지는 절대 문자열 안에 존재해야 했다.

이것은 한 종류의 모호성을 제거했을 뿐, 모든 종류의 권한 문제를 제거하지는 않았다. 명시적인 호스트명도 여전히 신뢰할 수 없는 당사자가 제공할 수 있다. 문법적으로 완전한 URL도 여전히 잘못된 운영자를 가리킬 수 있다. 퍼센트 인코딩된 구성 요소도 올바르게 파싱되면서 안전하지 않은 행동으로 이어질 수 있다. 완결성은 명령이 해석될 수 있다는 증거이지, 명령이 따라야 한다는 증거가 아니다.

인쇄된 대로 실행되지 않은 예제들

두 건의 후속 정정 사항은 증거 경계를 유난히 구체적으로 보여준다. 이 RFC는 APOP 교환을 인쇄했는데, 그 다이제스트는 표시된 서버 챌린지와 예제 비밀번호를 조합한 결과와 일치하지 않았다. 검증된 정정 사항 2943이 수정된 다이제스트를 제공했다. 또 다른 예제는SCRAM-MD5를 지명했지만, 그 시기에 관련 메커니즘은CRAM-MD5였다. 정정 사항 2942는 문서 업데이트를 위해 보류되었다. 이름을 바꾸면 인코딩된 교환도 함께 바꿔야 했기 때문이다.

이것들은 예제에 대한 좁은 수정이지, 배포된 사고의 증거도 아니고 URL 스킴에 대한 거부도 아니다. 그러나 유용한 훈련을 드러낸다. 대화 기록은 프로토콜처럼 보이면서도 바이트를 확인하면 실패할 수 있다. 메커니즘 이름은 그럴듯하게 들리면서도 구현이 실행할 수 있는 메커니즘을 식별하지 못할 수 있다. 표현, 파싱 성공, 자격 증명 공개, 인증 성공, 메일함 접근은 서로 다른 영수증이다.

실행되는 코드는 문장이 흐릿하게 만들 수 있는 구분을 용납하지 않는다. 수정된 다이제스트는 단순한 편집적 정돈이 아니다. 그것은 예시 문자열이 주장된 계산에 부합하는지 아닌지가 갈리는 지점을 표시한다.

작은 프로토콜, 큰 교훈

주변의 POP3 시스템은 의도적으로 단순했다. RFC 1939는 세션을 인가, 트랜잭션, 업데이트 상태로 조직했다. RFC 1734는AUTH명령을 추가했고, RFC 2222는 SASL 프레임워크를 제공했으며, RFC 2449는 나중에 서버에게 기능을 광고하는 방법을 주었다. RFC 2384는 그런 책임들을 URL 문법 안으로 흡수하려 하지 않았다.

이 절제가 중요하다. URL은 서비스에 접근하는 데 필요한 최소한의 휴대 가능한 설정을 담을 수 있었다. 이후의 결정은 증거가 실제로 평가될 수 있는 곳, 즉 클라이언트, 사이트 정책, 사용자 확인, 인증 교환에 남았다. 공통 계층은 결정론적으로 유지됐고, 위험한 결정은 국소적으로 남았다.

이 때문에 접속 성공이 최종 증명이 되지도 않는다. 클라이언트는 자격 증명 공개를 승인하지 않으면서 호스트에 접속할 수 있다. 의도된 메일함을 열지 않으면서 인증할 수 있다. 기대한 메시지를 검색하지 않으면서 메일함을 열 수 있다. 바이트를 검색하면서 올바르게 저장하거나 표시하지 않을 수 있다. 각 전이는 자기 자신의 관찰 가능한 결과를 필요로 한다.

RFC 2384는 메일함을 더 쉽게 지명할 수 있게 했다. 더 강한 역사적 교훈은, 목적지를 지명하는 것이 목적지에게 도달하는 데 필요한 자격 증명에 대한 권한을 부여하지는 않는다는 것이다.

출처