개요
이 제안서는 주소 헬퍼 URL에 인증 메커니즘을 추가합니다.
동기
주소 헬퍼 URL은 본질적으로 안전하지 않습니다. 누구든지 주소 헬퍼 매개변수를 링크에 넣을 수 있으며, 심지어 이미지를 위한 링크에도 넣을 수 있고, “i2paddresshelper” URL 매개변수에 어떤 목적지를 넣을 수도 있습니다. 사용자의 HTTP 프록시 구현에 따라, 이 호스트명/목적지 매핑은 주소록에 현재 없더라도, 사용자가 수락할 수 있도록 중간 경유 방식을 사용하여 수락될 수도 있습니다.
설계
신뢰할 수 있는 점프 서버와 주소록 등록 서비스는 인증 매개변수를 추가하는 새로운 주소 헬퍼 링크를 제공합니다. 두 가지 새로운 매개변수는 base 64 서명과 서명자 문자열입니다.
이 서비스들은 공개 키 인증서를 생성하고 제공합니다. 이 인증서는 다운로드 가능하며 HTTP 프록시 소프트웨어에 포함될 수 있습니다. 사용자와 소프트웨어 개발자는 인증서를 포함하여 이러한 서비스를 신뢰할지 결정하게 됩니다.
주소 헬퍼 링크를 만나면, HTTP 프록시는 추가 인증 매개변수를 확인하고 서명의 유효성을 검증하려고 시도합니다. 검증이 성공하면, 프록시는 기존과 같이 새 항목을 수락하거나 사용자가 수락할 수 있도록 중간 경유를 보여줍니다. 검증 실패 시, 프록시는 주소 헬퍼를 거부하거나 사용자에게 추가 정보를 표시할 수 있습니다.
인증 매개변수가 없는 경우, HTTP 프록시는 수락, 거부 또는 사용자에게 정보를 제공할 수 있습니다.
점프 서비스는 통상적인 신뢰성을 가지며, 추가 인증 단계를 거칩니다. 다른 사이트의 주소 헬퍼 링크는 수정이 필요합니다.
보안 문제점
이 제안서는 신뢰할 수 있는 등록/점프 서비스를 통한 인증을 추가함으로써 보안을 강화합니다.
명세
TBD.
두 가지 새로운 매개변수는 i2paddresshelpersig와 i2paddresshelpersigner일 수 있습니다?
허용되는 서명 유형 TBD. base 64 서명이 너무 길어 RSA는 아닐 가능성이 큽니다.
서명 알고리즘: TBD. 아마도 등록 인증을 위한 제안 112와 동일하게 hostname=b64dest?
가능한 세 번째 새로운 매개변수: HTTP 프록시에서 추가 검증을 위해 사용될 등록 인증 문자열("#!" 뒤의 부분). 문자열 내의 “#“는 “#” 또는 “#“로 이스케이프해야 하며, 또는 다른 지정된(TBD) URL 안전 문자로 대체해야 합니다.
마이그레이션
새로운 인증 매개변수를 지원하지 않는 구식 HTTP 프록시는 해당 매개변수를 무시하고 웹 서버로 전달하므로, 무해해야 합니다.
옵션으로 인증 매개변수를 지원하는 최신 HTTP 프록시는 이를 포함하지 않는 구식 주소 헬퍼 링크와 문제없이 작동할 것입니다.
인증 매개변수를 요구하는 최신 HTTP 프록시는 이를 포함하지 않는 구식 주소 헬퍼 링크를 허용하지 않을 것입니다.
프록시 구현의 정책은 마이그레이션 기간 동안 진화할 수 있습니다.
문제점
사이트 소유자는 자신의 사이트를 위한 주소 헬퍼를 생성할 수 없으며, 신뢰할 수 있는 점프 서버로부터의 서명이 필요합니다. 그는 신뢰할 수 있는 서버에 등록하고 인증된 헬퍼 URL을 그 서버로부터 받아야 합니다. 사이트가 자체 인증된 주소 헬퍼 URL을 생성할 방법이 있을까요?
대안으로, 프록시는 주소 헬퍼 요청에 대해 Referer를 확인할 수 있습니다. Referer가 존재하고, b32를 포함하며, 그 b32가 헬퍼의 목적지와 일치한다면, 자기 참조로 허용될 수 있습니다. 그렇지 않으면 제3자 요청으로 간주되어 거부될 수 있습니다.