클라이언트와 클라이언트 직접 연결

Direct Client-to-Client

DCC(Direct Client-to-Client)(원래 Direct Client Connection[1][2][3])는 IRC 관련 하위 프로토콜로 피어가 핸드셰이킹을 위해 IRC 서버를 사용하여 상호 연결하여 파일을 교환하거나 릴레이되지 않은 채팅을 수행할 수 있도록 한다. 일단 설정되면, 일반적인 DCC 세션은 IRC 서버와 독립적으로 실행된다. 원래 irc와 함께 사용하도록 설계됨II 그것은 현재 많은 IRC 고객들에 의해 지원되고 있다. 냅스터 프로토콜 서버의 일부 피어 투 피어 클라이언트도 TekNap, Sunshine을 비롯한 DCC 송신/겟 기능을 가지고 있다.UN과 Lopster. DCC 프로토콜의 변형인 SDCC(Secure Direct Client-to-Client, DCC SCHAT라고도 함)는 암호화된 연결을 지원한다. DCC 사용에 대한 RFC 규격은 존재하지 않는다.

DCC 연결은 다음과 같은 두 가지 방법으로 시작할 수 있다.

  • 가장 일반적인 방법은 CTCP를 사용하여 DCC 세션을 시작하는 것이다. CTCP는 IRC 네트워크를 통해 한 사용자로부터 다른 사용자에게 전송된다.
  • DCC 세션을 시작하는 또 다른 방법은 클라이언트가 DCC 서버에 직접 연결하는 것이다. 이 방법을 사용하면 IRC 네트워크를 통과하는 트래픽이 없다(DCC 연결을 시작하기 위해 관련 당사자를 IRC 네트워크에 연결할 필요는 없다).

역사

ircII는 CTCP와 DCC 프로토콜을 구현한 최초의 IRC 클라이언트였다.[4] CTCP 프로토콜은 1990년 마이클 샌드로프에 의해 irc를 위해 구현되었다.II 버전 2.1.[5] DCC 프로토콜은 1991년 Troy Rollo에 의해 버전 2.1.2에 대해 구현되었지만,[6] 다른 IRC 클라이언트에게 휴대할 의도는 없었다.[7][8]

일반적인 DCC 응용 프로그램

DCC 채팅

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

DCC CHAT은 일반적으로 CTCP 핸드셰이크를 사용하여 시작한다. 연결을 설정하고자 하는 사용자는 다음 CTCP를 대상에게 전송한다. DCC CHAT protocol ip port어디에 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자 이상의 파일 이름에 의해 트리거된[9] mIRC의 변형 버퍼 오버플로 오류와 포트 0의 사용에 의해 트리거된 Netgear, D-Link 및 Linksys가 제조한 일부 라우터의 입력 유효성 검사 오류라는 두 개의 버그를 나타낼 수 있다.[10][11] 특히, 라우터 공격은 실제 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어디에 resume position 시작할 파일의 오프셋이다. 여기서부터는 정상적인 DCC SEED로 이체가 진행된다.

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

RDCC

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

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

대상자는 CTCP에 다음과 같이 회신할 수 있다. RDCC 0 ip port어디에 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 명령어가 있다.

참고 항목

  • CTCP(Client-to-Client 프로토콜)
  • XDCC(eXtended DCC)

참조

  1. ^ https://www.troy.rollo.name/opensource.html
  2. ^ http://www.kvirc.net/doc/doc_dcc_connection.html
  3. ^ http://www.irchelp.org/protocol/ctcpspec.html
  4. ^ 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.
  5. ^ ircsi-2.1.4e.tar.gz에[permanent dead link] 포함된 'NOTES' 및 'source/ctcp.c' 파일을 참조하십시오.
  6. ^ ircsi-2.1.4e.tar.gz에[permanent dead link] 포함된 'UPDATES' 및 'source/dcc.c' 파일을 참조하십시오.
  7. ^ Troy Rollo (January 20, 1993). "/dcc". Newsgroup: alt.irc. Usenet: 1993Jan20.222051.1484@usage.csd.unsw.OZ.AU. Retrieved November 10, 2010.
  8. ^ Rollo, Troy. "A description of the DCC protocol". irchelp.org. Retrieved November 10, 2010. The first comment I should make is that the DCC protocol was never designed to be portable to clients other than IRCII. As such I take no responsibility for it being difficult to implement for other clients.
  9. ^ "SecurityFocus exploit information".
  10. ^ "'DCC Send' vulnerability on Netgear routers".
  11. ^ "'DCC Send' vulnerability on Linksys routers".

외부 링크