클라이언트 간 프로토콜

Client-to-client protocol

CTCP(Client-to-Client Protocol)는 IRC(Internet Relay Chat) 클라이언트 간의 특별한 통신 유형이다.

CTCP는 오늘날 사용되고 있는 대부분의 주요 IRC 클라이언트에 의해 구현되는 공통 프로토콜이다.[citation needed] CTCP는 사용자가 다른 클라이언트나 채널을 조회할 수 있도록 하여 원래의 IRC 프로토콜을 확장하며, 이로 인해 채널의 모든 클라이언트는 특정 정보에 대해 CTCP에 회신하게 된다. 또한, CTCP를 사용하여 새로운 선이나 바이트 값 0(NUL)을 포함하는 메시지와 같이 원시 IRC 프로토콜이 링크를 통해 전송되는 것을 허용하지 않는 메시지를 인코딩할 수 있다. CTCP는 클라이언트 간의 직접적인 연결을 설정하지 않지만, 일반적으로 DCC 연결을 협상하는 데 사용된다.

CTCP를 통해 사용자는 원격 클라이언트에 사용 중인 클라이언트의 버전에 대해 쿼리할 수 있다. CTCP VERSION() 또는 시간(을 통해) CTCP TIME), 그 중에서도. (을 통해) /me 명령어 구현에도 사용된다. CTCP ACTION).

역사

ircII는 CTCP와 DCC 프로토콜을 구현한 최초의 IRC 클라이언트였다.[1] CTCP 프로토콜은 1990년 마이클 샌드로프에 의해 irc를 위해 구현되었다.II 버전 2.1,[2] DCC 프로토콜은 1991년 Troy Rollo에 의해 버전 2.1.2에 대해 구현되었다.[3]

구조

CTCP 메시지는 다음과 같이 구현된다. PRIVMSG 또는 NOTICE 여기서 메시지의 첫 번째 문자와 마지막 문자는 ASCII 값 0x01이다. 또한 IRC 프로토콜에서 허용되지 않는 문자는 이스케이프된다. a이래 NOTICE 표준이 회신을 생성해서는 안 되기 때문에 CTCP 메시지는 다음과 같이 전송된다. PRIVMSG 그리고 응답은 다음 명령으로 구현된다. NOTICE a 대신에 PRIVMSG.

CTCP 쿼리는 대부분의 클라이언트에서 다음과 같이 시작된다. 

CTCP <표적> <명령> <논쟁>

여기서 <대상>은 대상 별명 또는 채널이며, <명령>은 CTCP 명령어(예: VERSION), 그리고 <<>>는 <대상>에 보내야 할 부가적인 정보다.

공통 CTCP 명령

이 섹션의 일부는 Direct Client-to-Client에서 벗어나 있다. (이력 편집)

CTCP 명령과 응답은 클라이언트마다 다르다. 따라서 IRC 클라이언트에 따라 다음과 같은 CTCP 명령 중 일부는 응답을 트리거하지 않거나 여기에 표시된 명령과 다르게 포맷될 것이다.

버전

A CTCP VERSION 요청은 대상이 사용 중인 IRC 클라이언트의 이름과 버전을 반환하며, 경우에 따라 운영 체제, 클럭 속도, CPU 제조업체 및 CPU 아키텍처/계기 집합과 같은 기술 정보를 반환한다.

A에 대한 샘플 응답 CTCP VERSION HexChat 클라이언트를 사용하는 대상에 대한 요청: 

VISION HexChat 2.9.1 [x86] / Windows 8 [1.46GHz]

시간

A CTCP TIME 요청은 대상 컴퓨터의 로컬 시간을 반환한다. IRC 클라이언트에 따라 회신은 날짜, 시간(12시간 형식 또는 24시간 형식), 연도(예: 2012년) 및 때때로 시간대(예: EST)로 구성될 수 있다.

A에 대한 샘플 응답 CTCP TIME ChatZilla 클라이언트를 사용하는 대상에 대한 요청: 

TIME Fri 23 2012년 11월 19:26:42 EST

핑

A CTCP PING 요청은 두 클라이언트 사이에 직접 존재하는 ping 속도를 결정한다(예: 서버 할인). 그 CTCP PING 명령어는 대상 클라이언트에 (수치) 정수 인수(타임스탬프)를 전송하여 작동하며, 대상 클라이언트는 정확히 동일한 숫자 매개변수를 제공함으로써 응답한다. 원래 타임스탬프와 현재 타임스탬프의 차이를 계산하여 CTCP PING을 시작한 사용자에게 결과를 표시한다. 대부분의 광대역 인터넷 연결 사용자들이 1초 미만의 ping을 가지고 있기 때문에 밀리초를 사용하는 타임스탬프가 사용되는 경우가 많다.

견본 CTCP PING XChat 클라이언트의 <닉네임> 타겟팅 요청: 

CTCP PING 23152511

마찬가지로 차이(위 참조)에서 생성되는 샘플 출력은 다음과 같다. 

<닉네임>의 ping 응답: 0.53초

DCC 채팅

CHAT 서비스는 DCC 연결을 통해 사용자가 서로 채팅할 수 있도록 한다. 트래픽은 IRC 네트워크를 통해서가 아니라 사용자 간에 직접 전달될 것이다. 정상적으로 메시지를 보내는 것과 비교하면, 이것은 IRC 네트워크 부하를 줄이고 홍수 조절의 부족으로 인해 한 번에 더 많은 양의 텍스트를 보낼 수 있으며, 메시지를 IRC 서버에 노출시키지 않음으로써 통신을 더욱 안전하게 만든다(그러나, 메시지는 여전히 일반 텍스트로 되어 있다).

DCC CHAT은 일반적으로 CTCP 핸드셰이크를 사용하여 시작한다. 연결을 설정하고자 하는 사용자는 다음 CTCP를 대상에게 전송한다. DCC CHAT protocol ip port, where ip 그리고 port 송신자의 IP 주소와 포트 번호로, 정수로 표현된다. protocol 이다 표준 DCC CHAT을 위한 채팅. 그러면 수신 당사자는 지정된 포트와 IP 주소에 연결할 수 있다.

일단 연결이 설정되면, DCC CHAT에 사용되는 프로토콜은 매우 간단하다: 사용자들은 CRLF 종료 메시지를 교환한다. ASC로 시작하는 메시지II 001(제어장치-A, 아래에 [^A]로 표시됨) 및 단어 ASC에 의해 종료되며, 다른 ASC에 의해 종료됨II 001은 이모티콘으로 해석된다. [^A]ACTION waves goodbye[^A].

DCC 화이트보드

이것은 DCC CHAT의 연장선으로, 간단한 도면 명령어뿐만 아니라 텍스트 행도 보낼 수 있다. DCC 화이트보드는 DCC CHAT과 유사한 핸드셰이크로 시작되며 프로토콜 채팅은 wboard로 대체된다. DCC CHAT wboard ip port.

연결이 설정되면 두 클라이언트는 CRLF 종료 메시지를 교환한다. ASC로 시작하고 선택적으로 끝나는 메시지II 001은 특수 명령으로 해석된다. 명령 ACTION은 에모테를 나타내는 반면, 다른 명령어는 사용자의 화이트보드 표면에 선을 긋게 하거나 두 클라이언트가 기능 집합을 협상하도록 허용한다.

DCC Send

SED 서비스는 사용자들이 서로 파일을 보낼 수 있게 해준다. 핸드셰이크의 원래 사양으로는 수신자가 총 파일 크기를 알 수 없었으며 전송을 재개할 수 없었다. 이것은 고객들로 하여금 악수에 그들 자신의 확장을 소개하게 만들었고, 그들 중 다수는 널리 지지를 받게 되었다.

원래의 핸드셰이크는 송신자가 수신자에게 다음과 같은 CTCP를 보내는 것으로 구성되었다. DCC SEND filename ip port.

DCC CHAT과 마찬가지로 ip 그리고 port 송신기가 수신 연결을 수신하는 IP 주소 및 포트. 일부 클라이언트는 파일 이름을 큰따옴표로 묶는다. 파일 크기를 마지막 인수로 추가하는 것이 일반적이다. DCC SEND filename ip port file size.

이 때, 원래의 사양은 수신기로 하여금 주어진 주소와 포트에 접속하여 데이터를 기다리거나 요청을 무시하게 하였으나, DCC RESPORT 확장을 지원하는 클라이언트의 경우, CTCP 회신을 보내 송신자에게 파일의 일부를 건너뛰도록 하는 것이 세 번째 대안이다. DCC RESUME filename port position.

만약 보낸 클라이언트가 DCC RESPORT를 지원한다면, 다음과 같이 회신할 것이다. DCC ACCEPT filename port position그리고 수신기는 주어진 주소와 포트에 접속하여 이미 존재하는 파일에 추가할 데이터를 들을 수 있다.

데이터는 블록으로 클라이언트에 전송되며, 각 블록은 32비트 네트워크 바이트 순서 정수 형태로 수신된 총 바이트 수를 전송하여 클라이언트가 확인해야 한다. 이것은 TCP 때문에 연결 속도를 늦추고 중복된다. 송수신 연장은 인가를 기다리지 않음으로써 이 문제를 다소 완화시키지만, 수신자는 여전히 수신하는 모든 블록에 대해 송수신해야 하기 때문에 발신인이 예상하는 경우에 대비하여 완전히 해결되지는 않는다.

또 다른 확장인 TDCC, 즉 터보 DCC는 인정은 제거하지만 약간 변형된 악수가 필요하며 널리 지원되지는 않는다. TDCC의 이전 버전은 TSEND와의 핸드셰이크에서 SEND라는 단어를 대체했으며, 이후 버전에서는 SEND라는 단어를 사용하지만 핸드셰이크 뒤에 T를 추가하여 이 버전의 TSEND가 다른 클라이언트와 호환되도록 했다(수정된 핸드셰이크를 구문 분석할 수 있는 한).

DCC SEND 취약성

DCC 송신 취약성은 14자 이상의 파일 이름에 의해 트리거된[4] mIRC의 변형 버퍼 오버플로 오류와 포트 0의 사용에 의해 트리거된 Netgear, D-Link 및 Linksys가 제조한 일부 라우터의 입력 유효성 검사 오류라는 두 개의 버그를 나타낼 수 있다.[5][6] 특히, 라우터 공격은 실제 DCC SEED 요청이 있을 때만이 아니라, 'DCC SEED' 문구에 이어 공백이나 새로운 줄이 없는 최소 6자 이상의 문자가 포트 6667의 TCP 스트림 어디에 나타날 때 촉발될 수 있다.

DCC XMIT

XMIT 서비스는 DCC SEED의 변형된 버전으로, 파일을 재개할 수 있고 ACK 장시간의 소모적인 트래픽을 줄일 수 있다. XMIT는 널리 지지되지 않는다.

XMIT 핸드셰이크는 Send 핸드셰이크와 다소 다르다. 송신자는 파일을 제공하는 CTCP를 수신자에게 전송한다. DCC XMIT protocol ip port[ name[ size[ MIME-type]]]

대괄호는 옵션 부품을 동봉한다. protocol 전송에 사용할 프로토콜이며, 현재 clear만 정의되어 있다. 표준 DCC SEED와 달리 ip IPv4에 대한 표준 점 표기법의 추가 형식 또는 IPv6에 대한 16진수 또는 혼합 표기 형식일 수 있다. 초기 매개변수를 비워두되, 이후 매개변수를 계속 공급하려면, 이전 매개변수를 -로 지정할 수 있다. 수신기가 사용되는 프로토콜을 구현하지 않을 경우, 다음 형식의 CTCP 회신을 다시 전송한다. ERRMSG DCC CHAT protocol unavailable.

여기서 CHAT은 확장 DCC CHAT이 보낸 오류 메시지와 호환성을 유지하기 위해 사용된다. 수신자가 전송을 거부할 경우, 다음과 같은 CTCP 회신을 보낸다. ERRMSG DCC CHAT protocol declined.

다른 오류들도 같은 방식으로 보고된다. 만약 수신자가 파일을 받을 의지와 능력이 있다면, 그것은 주어진 주소와 포트에 연결될 것이다. 그때 일어나는 일은 사용된 프로토콜에 따라 달라진다.

클리어 프로토콜의 경우, XMIT 서버는 연결을 수신할 때 32비트를 전송한다. time t 파일의 수정 시간을 나타내는 네트워크 바이트 순서로. 로컬 파일의 수정 시간을 기준으로 클라이언트가 다른 네트워크 바이트 순서를 전송함 long파일을 전송할 때 서버가 찾아야 하는 오프셋. 파일 전체를 원하는 경우 0으로 설정하거나 클라이언트가 이전 다운로드를 재개하려면 로컬 파일의 크기를 설정해야 한다.

XMIT는 SEND보다 빠르지만, CTCP 협상에서 파일의 크기를 명시하거나 미리 알리지 않는 한 파일의 크기를 알 수 없다는 점에서 동일한 제한사항 중 하나를 안고 있다. 더욱이 32비트 오프셋 때문에 2기가바이트를 넘는 파일을 재개할 수 없다.

패시브 DCC

정상적인 DCC 연결에서 이니시에이터는 서버 역할을 하며, 대상은 클라이언트다. NAT으로 인해 광범위한 방화벽 설치 및 엔드 투 엔드 투명성 감소로 인해 이니시에이터가 서버 역할을 하지 못할 수 있다. 대상이 서버 역할을 하도록 요청하는 다양한 방법이 고안되었다.

DCC 서버

정상적인 DCC SEED 및 CHAT에 대한 이 확장은 IRC 클라이언트 mIRC에 의해 도입되었다. DCC 서버는 중간 정도의 지원을 받지만 모든 클라이언트에서 표준이 되는 것은 아니다(인터넷 릴레이 채팅 클라이언트 비교 참조).

IRC 서버 없이도 IP 주소로 DCC 연결을 시작할 수 있다. 이는 수신 클라이언트가 서버(이름 확인) 역할을 수행하면서(보통 포트 59에서) 발신인의 핸드셰이크를 수신함으로써 이루어진다.

CHAT의 경우 이니시에이터가 전송 1000 initiator nick그 다음 타깃은 다음과 같이 대답한다. 1000 target nick, 그리고 나머지는 표준 DCC CAT 프로토콜에 따라 진행된다.

SEND의 경우 이니시에이터가 전송 1200 initiator nick filesize filename타겟은 다음과 같이 대답한다. 1210 target nick resume position, where resume position 시작할 파일의 오프셋이다. 여기서부터는 정상적인 DCC SEED로 이체가 진행된다.

DCC 서버는 mIRC 스타일의 파일 서버와 DCC GET도 지원한다.

RDCC

DCC 서버는 사용할 포트를 명시할 수 있는 방법을 제공하지 않으므로, 이것은 수동으로 협상되어야 하며, 이는 측면 중 하나가 사람이 아닐 수 있기 때문에 항상 가능한 것은 아니다. RDCC는 DCC 서버를 위한 핸드셰이크 메커니즘으로, 포트 외에 서버의 IP 주소도 제공하며, 호스트 마스킹 때문에 클라이언트가 다른 방법으로 찾을 수 없을 수도 있다. 그것은 널리 지지되지 않는다.

이니시에이터는 CTCP 쿼리를 전송하여 대상이 수신 중인 포트를 요청하며, RDCC function comment, where function 채팅용 c, 전송용 s, 파일 서버용 f.

대상자는 CTCP에 다음과 같이 회신할 수 있다. RDCC 0 ip port, where ip 그리고 port 일반적인 DCC SEND 및 CHAT과 같은 의미를 갖는다. 이 후 이니시에이터는 에 연결된다. ip 그리고 port, 그리고 DCC 서버 핸드셰이크가 이어진다.

DCC 리버스

직접 IP 연결을 통해 핸드셰이크를 처리하는 DCC 서버와 달리 DCC REVERSE는 DCC SEED에서 사용하는 것과 유사한 CTCP 핸드셰이크가 일반적이다. 이것은 널리 실행되지 않는다. 송신자는 CTCP 메시지를 보내 수신자에게 파일을 제공한다. DCC REVERSE filename filesize key. key 33-126 범위의 1-50자 길이의 ASCII 문자 문자열이며, 전송의 식별자 역할을 한다.

수신자가 수락하면 CTCP 회신을 보내며, DCC REVERSE key start ip port

여기, start 전송을 시작할 파일의 위치, ip IPv4에 대한 표준 점 표기법으로 수신기의 IP 주소 또는 IPv6에 대한 16진 표기법이다. 송신자는 수신자가 가리키는 IP 주소와 포트에 접속하고, 정상적인 DCC SEED가 뒤따른다. 송신자와 수신자 모두 CTCP 회신을 보내 핸드셰이크를 취소할 수 있다. DCC REJECT REVERSE key.

DCC RSEND

이것은 KVIrc 클라이언트의 DCC REVERSE 대안이다. 발신인은 CTCP: DCC RSEND filename filesize수신자는 CTCP에 회신하여 수락할 수 있다. DCC RECV filename ip port start그리고 송신자는 수신기에 접속하여 정상적인 DCC SEED 동안과 같이 송신한다.

후진/방화벽 DCC

이 수동형 DCC 메커니즘은 적어도 mIRC, Visual IRC, HexChat, KVIrc, DMDirc, Klient, Conversation 및 Phibian에 의해 지원된다.IRC. 발신인은 CTCP 메시지를 보내 파일을 제공한다. DCC SEND filename ip 0 filesize token. ip 네트워크 바이트 순서에 따른 송신자의 IP 주소로서, 하나의 정수(표준 DCC와 동일)로 표현된다. 유효한 포트 대신 숫자 0이 전송되어 이것이 역 DCC 요청임을 알린다. token TSEND가 (지원하는 클라이언트에 의해) 사용되고 있는 경우, TSEND라는 문자가 토큰에 추가되어 수신자에게 확인을 보낼 필요가 없음을 알린다.

수신기는 청취 소켓을 열고 CTCP 메시지로 응답함으로써 파일을 수신할 수 있다. DCC SEND filename ip port filesize token. 이것은 원래 Reverse DCC 메시지와 동일하다. 단, ip 그리고 port 수신기가 듣고 있는 소켓을 확인한다. token 어떤 요청이 받아들여지고 있는지 발신인에게 알려주는 원래의 요청과 동일하다. (이 메시지는 일반 DCC 송신 요청과 동일한 형식을 따르므로, DCC 요청을 필터링하는 일부 서버는 송신자에게 "DCC 허용" 목록에 수신기를 추가하도록 요구할 수 있다.)

송신자는 이어 수신기의 소켓에 접속해 파일의 내용을 전송하고, 파일이 끝나면 수신기가 소켓을 닫을 때까지 기다린다.

SEED 프로토콜에 대한 RESPORT 확장이 사용될 때, 명령의 순서는 개시 측에서 발신 메시지를 나타내는 ( >와 함께)가 되고, << 피어의 응답>이 된다.

>> DCC SEND filename ip 0 filesize token
<< DCC RESUME filename 0 position token
>> DCC ACCEPT filename 0 position token
<< DCC SEND filename peer-ip port filesize token

그 후에 프로토콜은 정상적으로 진행된다(즉, 송신자가 수신기의 소켓에 연결).

파일 서버(FSERV)

DCC fserve 또는 파일 서버는 사용자가 DCC 서버에 있는 파일을 검색, 읽기 및 다운로드하도록 한다.

일반적으로 이것은 DCC CHAT 세션(사용자에게 명령 프롬프트를 제시)이나 파일을 요청하기 위한 특수 CTCP 명령으로 구현된다. 파일은 DCC Send 또는 DCC XMIT를 통해 전송된다. DCC 파일 서버의 구현이 많은데, 그 중에는 인기 있는 mIRC 클라이언트의 FSERV 명령어가 있다.

참고 항목

참조

  1. ^ Piccard, Paul; Brian Baskin; George Spillman; Marcus Sachs (May 1, 2005). "IRC Networks and Security". Securing IM and P2P Applications for the Enterprise (1st ed.). Syngress. p. 386. ISBN 1-59749-017-2. The authors of the ircII software package originally pioneered file transfers over IRC.
  2. ^ ircsi-2.1.4e.tar.gz에[permanent dead link] 포함된 'NOTES' 및 'source/ctcp.c' 파일을 참조하십시오.
  3. ^ ircsi-2.1.4e.tar.gz에[permanent dead link] 포함된 'UPDATES' 및 'source/dcc.c' 파일을 참조하십시오.
  4. ^ "SecurityFocus exploit information".
  5. ^ "'DCC Send' vulnerability on Netgear routers".
  6. ^ "'DCC Send' vulnerability on Linksys routers".

외부 링크