요약

  • 1977년의 RFC 742 NAME/FINGER 서비스는 빈 CRLF 줄을 온라인에 접속한 모든 사람에 대한 요청으로 취급했으며, 이름, 터미널 위치, 유휴 시간 등 유용하다고 여겨지는 사람 중심 정보를 함께 반환했습니다.
  • RFC 1288은 한 줄짜리 TCP 교환은 그대로 유지하면서 정책을 가시화했습니다. 서버는 전체 사용자 목록이나 전달을 능동적으로 거부할 수 있고, 관리자는 어떤 개별 정보 필드를 공개할지 선택해야 합니다.
  • Finger는 질문과 그 만남 지점인 TCP 포트 79를 표준화했습니다. 그러나 대상을 인증하지 않았고, 답을 보장하지 않았으며, 데이터에 대한 권리를 부여하지도, 사람이 읽는 신뢰할 수 없는 출력을 안전하게 표시되도록 만들지도 않았습니다.

빈 줄은 의미 있는 명령이었다

가장 많은 것을 드러낸 Finger 요청은 사실상 아무것도 담지 않았습니다. 클라이언트는 8진수로 117, 즉 10진수로 79인 소켓에 접속해 CRLF를 보내고 기다렸습니다. 1977년 12월 30일자RFC 742는 그 결과를 기본 보고서로 규정했습니다. 바로 그 시점에 원격 시스템을 사용하는 모든 사람의 목록이었습니다.

권장 최소 항목은 사람과 관련된 것이었습니다. 목록에는 전체 이름이 담겨야 했고, 시스템이 판별할 수 있는 경우 터미널의 물리적 위치도 담겨야 했습니다. 작업 이름과 유휴 시간도 합리적이고 유용한 것으로 기술되었습니다. 사용자 이름을 포함한 질의는 대상을 군중에서 한 사람으로 좁혔습니다. 그 사람이 로그인 중인지, 마지막으로 로그아웃한 시각, 그리고 별도로 지정된 파일에 남긴 짧은 '계획(plan)' 메시지를 보고할 수 있었습니다.

이것은 친근한 인터페이스를 쓴 기계용 기록 프로토콜이 아니었습니다. 응답은 명시적으로 사람을 위해 설계되었습니다. 요구되는 출력 형식은 없었습니다. 클라이언트가 한 줄의 명령을 보내면, 그 호스트가 생성한 어떤 유익한 텍스트든 받고, 서버는 작업을 마치면 연결을 닫았습니다.

이 단순함은 프로토콜이 시작된 공동체를 반영했습니다. RFC 742는 SAIL, SRI와 여러 ITS 시스템을 당시의 서버로 지목했습니다. 문서는 Les Earnest가 작성한 SAIL의 FINGER 프로그램을 ITS의 NAME 프로그램에서 그 기원을 찾아 설명하고, 네트워크 프로토콜은 Earl Killian과 Brian Harvey에게 돌렸습니다. 이미 네트워크 접속 상태를 협업의 일부로 여기던 사람들 사이에서 원격 상태 게시판은 자연스러운 발상이었습니다.

그러나 빈 줄에는 구조적 선택이 담겨 있었습니다. 목록을 요청하는 사람은 대상을 지정하거나, 목적을 밝히거나, 그 사이트와의 관계를 증명할 필요가 없었습니다. 기본 질문은 집단적이었습니다. 여기 누가 있나? 네트워크가 작은 무리를 넘어 성장한 뒤에도 편의는 줄지 않았습니다. 줄어든 것은 그 편의를 누리는 사람의 범위였습니다.

사람 중심 출력이 프로토콜을 넓게 만들었다

Finger는 고정된 필드 배치를 강제하지 않았기 때문에, 응답은 현지의 상상력에 따라 커질 수 있었습니다. RFC 742의 예에는 로그인 이름, 성명, 작업, 터미널, 방, 콘솔 위치, 원격 사이트, 마지막 로그인 정보, 사용자 계획이 포함됩니다. 이후의 실무에서는 사무실과 집 전화번호, 디렉터리 경로, 셸, 메일 상태가 추가될 수 있었습니다.

이 느슨함은 시스템마다 담고 있는 정보가 다르다는 점에서 유용했습니다. 동시에 상호운용성이 문제의 일부만 해결한다는 뜻이기도 했습니다. 두 프로그램이 포트 79, CRLF, 연결 종료에는 합의하면서, 그 텍스트에서 사람이 무엇을 알아야 하는가에 대해서는 전혀 다른 견해를 가질 수 있었습니다.

/W토큰은 이 긴장을 명시적으로 만들었습니다. 초기 문서에서 이는 Whois 스위치로 불리며 더 자세한 설명을 요청했습니다.RFC 1288은 이후/W를 질의 문법의 맨 앞에 두고, 마지막 서버가 이를 더 높은 상세 수준으로 해석하거나 무시할 수 있도록 허용했습니다. 더 많은 세부 정보는 별도의 인증된 작업이 아니었습니다. 같은 최소한의 채널 안에 있는 하나의 요청이었습니다.

이름조차 확장될 수 있었습니다. 서버는 로그인 이름을 이해해야 했지만, 성이나 전체 이름도 받아들일 수 있었습니다. 모호한 이름은 후보 여러 명을 반환할 수 있었습니다. 동료를 찾도록 돕기 위해 설계된 기능은, 전체 사용자 질의가 비활성화된 뒤에도 열거 경로가 될 수 있었습니다.

친절한 기본값에서 명시적 거부로

프로토콜은 그 사회적 맥락이 바뀐 뒤에 다시 작성되었습니다. 1990년 12월에 발표된RFC 1196은 널리 퍼져 있던 BSD 계열의 동작을 기술하면서, 시스템의 사용자 정보를 반환하는 것은 '기껏해야' 민감하다고 경고했습니다. 이 문서는 이미 사용 중인 수많은 구현을 무효화하지 않으면서 교환을 명확히 하려 했습니다.

RFC 1288은 1991년 12월에 뒤따랐고,/W의 위치를 바로잡고, 공백 문법을 정확히 하고, 연결 종료를 더 면밀히 규정했습니다. 와이어 교환은 그대로 작았습니다. TCP 포트 79를 열고, CRLF로 끝나는 한 줄의 ASCII를 보내고, 답을 받고, 연결을 닫습니다. 큰 변화는 메시지 크기가 아니라 결정권자였습니다.

빈{C}질의에 대해 서버는 답하거나 능동적으로 거부해야 했습니다. 답한다면 응답에는 최소한 전체 이름이 포함되며, 관리자는 터미널이나 사무실 위치, 사무실 전화, 작업 이름, 유휴 시간을 추가할지 선택할 수 있어야 했습니다. 접속 사용자 목록이 비활성화되어 있다면, 서버가 아무도 접속하지 않은 것처럼 가장할 필요는 없었습니다. 명시적 거부를 반환할 수 있었습니다.

이 구분은 중요합니다. 빈 결과는 세계에 대한 사실로 읽힐 수 있습니다. 거부는 정책에 대한 사실입니다. 이후 규격은 능동적 부정 응답을 표준화함으로써, 수신하는 사람이 '서비스가 아무도 없다고 보고한다'와 '이 호스트는 접속 인원을 노출하지 않는다'를 구분할 수 있게 했습니다.

RFC 1288은 다음 제어 수준을 '원자적 공개(atomic discharge)'라 불렀습니다. 구현은 관리자가 어떤 정보의 원자를 반환할지 조정할 수 있어야 합니다. 어떤 사이트는 사무실과 집 전화번호와 로그인 시각을 공개할 수 있고, 어떤 사이트는 사무실 위치와 전화만 반환할 수 있으며, 어떤 사이트는 요구되는 전체 이름에서 멈출 수 있습니다. 네트워크 문법은 더 이상 하나의 보편적 공개 묶음을 내포하지 않았습니다.

전달은 경계를 뚫을 수 있었다

Finger 질의는@hostname구성 요소의 연쇄도 지원했습니다. Q2 요청은 하나의 원격 사용자 정보 프로그램에게 다른 Finger 연결을 열어 남은 질의를 전달하도록 했습니다. 문법은 호스트 토큰 수에 임의의 상한을 두지 않았습니다.

여기서도 RFC 1288은 가시적인 정책 결과를 요구했습니다. 서버는 전달을 제공하거나 능동적으로 거부해야 했습니다. 권고는 기본적으로 거부하는 것이었으며, 특히 게이트웨이에서 그러했습니다. 게이트웨이가 외부의 질의를 받아 내부 호스트로 보낸다면, 친절한 디렉터리 서비스가 보안 경계를 통과하는 경로가 되어 버립니다.

전달은 원래의 질문을 인증하지 않았고, 내부 응답을 공개 데이터로 바꾸지도 않았습니다. 다음 서비스에 도달할 수 있는 기계를 바꿀 뿐이었습니다. 첫 TCP 연결만 고려한 사이트는 실제 공개 경로를 오해할 수 있었습니다.

제어의 교훈은 Finger보다 넓습니다. 릴레이는 문법적으로 충실하면서도 누가 누구에게 물을 수 있는지를 바꿀 수 있습니다. 모든 홉이 같은 프로토콜을 사용한다고 해서 권한이 보전되는 것은 아닙니다.

계획 파일은 작성자를 옮겼지만 영향 범위는 담지 않았다

계획(plan) 기능은 사용자에게 목소리를 주었습니다. 어떤 사람은 이후의 Finger 질의를 위해 짧은 메시지를 남길 수 있었습니다. 근무 시간, 여행 일정, 연락 방법, 프로젝트 메모 같은 것입니다. 네트워크에 보이는 상태 필드의 작은 선조였습니다.

그러나 그 텍스트가 어디로 흘러가는지는 작성자가 아니라 서버가 결정했습니다. RFC 1288은 사용자가 수정 가능한 파일을 반환하는 것은 시스템에 대한 임의의 정보가 자유롭게 배포되는 것을 허용하는 것으로 취급해야 한다고 경고했습니다. 사용자는 민감한 내용을 의도적으로 공개하거나, 오해를 일으키는 자료를 심거나, 그 파일을 수집하는 프로그램의 가정을 악용할 수 있었습니다.

일부 구현은 질의에 응답해 사용자 프로그램을 실행할 수 있었습니다. RFC는 이를 더 위험한 옵션으로 다뤘습니다. 이제 네트워크 입력이 로컬 운영체제 제약 아래에서 실행 동작을 촉발할 수 있게 되는 것입니다. 관리자는 이 기능을 끌 수 있어야 했고, 구현은 그 프로그램이 시스템 보안을 훼손하지 못하도록 해야 했습니다.

이 기능들은 쉽게 하나로 뭉개지는 세 가지 권한을 분리합니다. 사용자는 텍스트를 작성할 수 있습니다. 운영자는 그것을 노출하거나 감출 수 있습니다. 원격 클라이언트는 그것을 어떻게 렌더링할지 결정합니다. 한 계층의 동의가 다른 두 계층을 조용히 결정하지는 않습니다.

읽을 수 있는 답도 여전히 신뢰할 수 없는 입력이었다

Finger의 응답 형식이 느슨했던 이유는, 그것을 읽는 것이 파서가 아니라 사람이어야 했기 때문입니다. 그렇다고 그 바이트가 무해해지지는 않았습니다. RFC 1288은 클라이언트가 기본적으로 인쇄 불가능한 데이터를 걸러내고, 인쇄 가능한 7비트 문자, 탭, CRLF만 남길 것을 권고했습니다. 언급된 우려에는 다른 사람의 X 윈도우 이름을 바꾸거나 다른 혼란스러운 동작을 할 수 있는 터미널 이스케이프 시퀀스도 포함되었습니다.

위험은 양방향으로 흘렀습니다. RFC 742는 이미 범용 Telnet 클라이언트를 사용하면 Telnet 옵션 협상 바이트가 Finger 명령줄에 주입될 수 있다고 경고한 바 있었습니다. 텍스트를 운반한다는 이유로 호환되어 보이는 도구가, 서버가 해석하기 전에 애플리케이션 메시지를 바꿔버릴 수 있었습니다.

따라서 프로토콜의 사람 지향성은 두 가지 안전 의무를 만들었습니다. 발신 클라이언트는 대화형 제어 트래픽이 아니라 한 줄짜리 Finger 문법을 내보내야 했습니다. 수신 클라이언트는 답을 터미널 지시문이 아니라 신뢰할 수 없는 텍스트로 취급해야 했습니다. '사람을 위한'은 의도된 독자를 설명할 뿐, 보안 속성이 아니었습니다.

구현과 정보는 별개의 위험이었다

RFC 1288은 Finger 구현에 침투 테스트를 요구하면서 모리스 웜(Morris worm)을 언급합니다. 이 문서는 Finger를 Telnet, FTP, SMTP와 함께 호스트의 보안 경계에 놓습니다. 이 근거는 좁은 결론을 뒷받침합니다. 작은 질의 프로토콜이라도 코드를 적대적 입력에 직접 노출시킬 수 있습니다.

이 RFC는 이어서 구현 보안과 공개 보안을 분리합니다. 메모리 안전하고 정확히 파싱하는 서버라도 누가 접속 중인지, 누군가 언제 메일을 마지막으로 읽었는지, 읽지 않은 메일이 존재하는지, 가장 최근의 읽지 않은 메일을 누가 보냈는지를 드러낼 수 있습니다. 이 문서는 그러한 세부 사항이 대화와 주의 방향을 드러낼 수 있다고 경고합니다.

반대로 정책을 최소화한 응답이 데몬의 안전을 증명하지는 않습니다. 변형된 입력, 재귀적 전달, 실행 가능한 사용자 훅, 출력 처리는 여전히 구현의 문제로 남았습니다. 프로세스를 보호하는 것과 데이터를 제한하는 것은 서로 관련된 제어이지 대체물이 아니었습니다.

로깅이 정책의 고리를 완성했습니다. 구현은 관리자가 Finger 질의를 기록할 수 있어야 했습니다. 그 기록은 어떤 이름이 요청되었는지, 열거가 반복되는지, 전달이 사용되었는지를 보여줄 수 있었습니다. 동시에 그것은 사람의 관심에 대한 기록이 되므로, 자체적인 보존 기간과 접근 정책을 요구했습니다.

등록된 포트는 문을 조율했지 권리를 부여하지 않았다

현재의IANA 서비스 이름 및 전송 프로토콜 포트 번호 레지스트리는 TCP와 UDP에 대해 포트 79의finger를 기록하고 있습니다. RFC 1288은 이 서비스를 TCP 위에서 정의합니다. 레지스트리는 구현이 서비스를 찾을 수 있는 공통의 장소를 보존합니다.

레지스트리는 호스트가 Finger를 실행한다고 말하지 않고, 서비스가 안전하다고 말하지 않으며, 응답이 최신이라고 말하지 않고, 요청자가 어떤 특정 필드를 받을 권리가 있다고도 말하지 않습니다. 잘 알려진 포트는 만남 지점을 조율할 뿐입니다. 응답하는 운영자는 여전히 노출을 통제하고, 사용자는 운영자가 허락한 자료만 통제하며, 수신자는 그 텍스트에 어떤 의미를 부착할지 여전히 통제합니다.

바로 여기서 Finger는 정식 디렉터리 기록과 갈립니다. Finger는 응답하는 호스트가 사람과 세션을 바라보는 그 시점의 시야, 종종 자기 작성 상태로 보완된 시야를 노출했습니다. 서명된 신원 단정이나 행정적 보관 증거 사슬을 공개하지는 않았습니다.

질문은 기본 권위를 잃는 방식으로 살아남았다

Finger의 역사적 궤적은 순진함 뒤에 보안이 따라온 것으로 쉽게 왜곡됩니다. 문서들은 더 정확한 무언가를 보여줍니다. 1977년의 프로토콜은 이미 출력이 달라질 수 있고, 평범한 Telnet 동작이 명령을 방해할 수 있음을 알고 있었습니다. 이후의 표준은 그 사람적 가치를 버리지 않았습니다. 그 가치를 둘러싼 선택들을 검사 가능하게 만들었습니다.

빈 질의는 여전히 접속 중인 모든 사람에 대한 요청이었지만, 서버는 거부할 수 있었습니다. 이름이 지정된 질의는 여전히 풍부한 프로필을 반환할 수 있었지만, 관리자가 필드를 선택해야 했습니다. 전달된 질의는 문법적으로 여전히 가능했지만, 거부가 권고되는 기본값이었습니다. 계획은 여전히 개인적일 수 있었지만, 사용자의 작성이 그 배포를 무해하게 만들지는 않았습니다. 사람이 읽을 수 있는 응답은 여전히 유연했지만, 클라이언트는 제어 문자를 걸러내야 했습니다.

그 결과는 프로토콜에 의한 프라이버시가 아니었습니다. 프라이버시 정책이 어디에 자리해야 하는지를 드러내는 데 충분히 솔직한 프로토콜이었습니다. 포트 79는 어디에 물을지 대답했습니다. 운영자는 공개할지 여부를 대답했습니다. 클라이언트는 얼마나 안전하게 표시할지 대답했습니다. 어느 계층도 다른 계층을 대변할 권리를 얻지 못했습니다.

출처와 근거의 한계

위의 닫힌 출처들은 프로토콜 역사, 문법, 보안 지침, 포트 등록을 확립합니다. 이들은 현재의 배포 상황, 공격 빈도, 특정 사이트의 공개 관행을 측정하지 않습니다. 따라서 이 글은 IANA 기록을 Finger가 오늘날 활성화되어 있다는 근거로 취급하지 않으며, 모든 역사적 구현이 RFC 예시에 나온 모든 필드를 반환했다고 주장하지도 않습니다.