Ricochet: 파일 전송

와, 이것은 오래된 문제입니다. 이제 완료할 시간입니다. 파일 전송에 대해 알아보겠습니다. 이것은 부분적으로는 피드백을 요청하고, 부분적으로는 나 자신을 설득하고, 부분적으로는 브레인덤프이지만 유용하기를 바랍니다.

UX

파일 전송에 대한 두 가지 유형의 사용 사례가 있습니다. 활성 사용자 는 대화 중에 파일을 보내고 받으며 파일이 대화의 일부가 되기를 기대합니다. 파일 삭제 는 온라인 상태를 유지하고 즉시 활성화되지 않더라도 언제든지 파일을 수신할 수 있기를 원하는 소수의 Ricochet 사용자를 위한 것입니다.

대부분의 메시징 응용 프로그램과 마찬가지로 우리 는 대화의 일부로 파일 전송을 인라인으로 수행하기를 원하며 다른 응용 프로그램(브라우저 포함)을 사용할 필요가 없어야 합니다.

파일을 대화로 끌어다 놓는 것은 파일을 보내는 일반적인 방법입니다. 틀림없이 이런 식으로 실수로 파일을 보내는 것이 쉬울 수 있습니다. 파일 을 메시지 입력 상자에 놓고 보내기 전에 메시지를 입력하거나 보내기 전에 카운트다운을 사용하면 더 쉽게 이를 완화할 수 있습니다. 대화 헤더의 버튼이나 메시지 입력 근처에 파일을 보내기 위한 또 다른 가시적인 UI 메서드 가 있어야 합니다.

제공된 파일 은 사용자가 잊어버렸을 수 있다고 합리적으로 가정하기에 충분한 시간 후에

Ricochet의 위협 모델은 대화 데이터(파일 포함)를 자동으로 저장하는 것을 금지합니다. 위협 모델은 연락처를 잠재적인 공격자로 간주하므로 연락처가 사용자 승인 없이 트리거할 수 있는 일련의 작업을 줄이고자 합니다. 이는 파일 전송에 대해 기본적으로 명시적 수락을 요구 해야 함을 시사합니다. 사용자는 기본 위치를 구성하지 않는 한 각 파일을 저장할 위치를 명시적으로 선택해야 합니다. 이것은 활성 사용자 사용 사례에서는 문제가 없지만 파일 삭제의 경우 파일 을 자동으로 저장 하는 합니다 (연락처별로도 가능).

활성 제안 또는 전송은 양 당사자가 쉽게 알아볼 수 있어야 합니다. 대화 에서 전송 대화 헤더 (전송 탭?) 및/또는 전역 전송 상태에 진행 상황이 어딘가에 있어야 합니다. 전송이 진행되는 동안 대화가 계속 진행될 수 있기 때문에 이는 특히 중요합니다. 전송이 완료되면 대화 의 끝 으로

브라우저 경고와 유사한 경고와 함께 을 클릭하면 완료된 전송이

Tor는 신뢰할 수 없는 것으로 알려져 있으므로 재개하는 능력이 중요합니다. 가능할 때마다 자동으로 다시 연결하고 기존의 불완전한 파일 위에 저장하여 재개할 수 있어야

미래의 UX

대화와 함께 인라인 으로 이미지 디코더를 신뢰하지 않는다는 점을 제외하고 파일 전송이 완료되면 이 작업을 수행하기 쉽습니다. 강력하고 메모리가 안전한 디코더 또는 플랫폼 간 seccomp 스타일 샌드박싱을 찾으면 이 작업을 수행할 가치가 있습니다.

누군가는 우리가 적어도 연결을 구축하고 메모리 내 제한까지 버퍼링하여 파일을 미리 가져올 수 있다고 지적하여 전송 프로세스가 더 빠르게 보이도록 했습니다.

파일 또는 전체 폴더의 일괄 전송을 합리적인 한도까지 허용하는 것이 좋습니다.

전송 서버에서 다운로드한 파일 의 해시 를 자동으로

규약

사이

파일 데이터는 Ricochet의 기본 프로토콜 연결을 통해 보낼 수 없습니다. 데이터를 패킷화하더라도 Tor 스트림의 버퍼링 속성 때문에 숨겨진 서비스 연결이 플러딩될 때 매우 많은 양의 데이터가 대기열에 있습니다. 이로 인해 해당 스트림에 대해 극도의(종종 30초 이상) 대기 시간이 발생합니다. 다른 형태의 속도 제어는 전송 속도에 너무 많은 영향을 미칩니다.

간단한 대답은 피어 서비스에 대한 추가 연결을 여는 것입니다. 이러한 연결은 Tor에 의해 동일한 회로에 다중화되지만 버퍼링 동작은 훨씬 더 좋습니다. 일반 테스트에서는 동일한 회로의 다른 스트림으로 데이터를 플러딩할 때 메시지 대기 시간에 큰 영향을 미치지 않는 것으로 보입니다.

또한 회로 격리 옵션을 사용하여 Tor가 전송을 위한 새 회로를 구축하도록 할 수도 있습니다. 이것이 처리량이나 대기 시간에 유용한지 여부는 불분명하며 추가 동시 회선을 구축하면 익명성 또는 트래픽 분석에 상당한 영향을 미칠지 여부도 불분명합니다.

Ricochet의 프로토콜은 어떤 연결을 사용해야 하는지 모호하고 메시지 순서에 대한 기대치를 위반할 수 있기 때문에 연락처당 둘 이상의 인증된 연결을 허용하지 않습니다. 추가 연결이 Ricochet의 프로토콜을 사용하는 경우 연결이 데이터 전송에만 사용됨을 나타내기 위해 다르게 인증해야 합니다.

데이터 전송은 2차 연결을 통해 이루어지기 때문에 Ricochet의 프로토콜로 데이터를 패키징할 필요가 없습니다. 여기에서 옵션을 생각해 볼 가치가 있습니다.

옵션 1: 수정된 Ricochet 프로토콜

내 원래 생각은 추가 연결에서 파일 데이터 전송을 위해 Ricochet의 프로토콜을 사용하는 것이었습니다. 이것은 완전히 간단하지 않습니다.

혜택:

• 프로토콜 연결을 통해 인라인으로 작은 파일을 쉽게 보낼 수 있음
• 기존 프로토콜과 더 일치
• 새로운 파서/서버 공격 표면 없음

단점:

• 기본 연결은 하나만 있을 수 있으므로 인증이 이상하게 됩니다.
• 더 깊은 프로토콜 수정을 하지 않는 한 데이터는 헤더가 있는 최대 65kb 청크로 분할되어야 합니다.
• 프로토콜 설계 및 구현이 제대로 이루어지기 어렵습니다.

FileTransferChannel.proto 및 FileTransferDataChannel.proto 의 WIP 분기에서 이것이 어떻게 보이는지에 대한 오래된 작업이 있습니다.

옵션 2: HTTP(현재 기본 설정)

Ricochet 클라이언트는 OnionShare 와 유사한 간단한 내부 서버와 고유한 URL을 사용하여 HTTP를 통해 파일을 제공할 수 있습니다. 해당 서버는 동일한 숨겨진 서비스, 새로운 임시 서비스의 다른(임의의) 포트에 있거나 프로토콜 감지를 사용하여 동일한 포트를 공유할 수도 있습니다.

혜택:

• 보다 강력한/표준/미래 대비 구현
• 수신자 역호환성: URL 표시로 자연스럽게 대체할 수 있습니다.
• 수신자가 브라우저 및 기타 도구를 사용하여 다운로드 가능
• 연락처가 아닌 사람에게도 파일을 제공하는 데 사용할 수 있습니다.

단점:

• 아주 최소한의 HTTP 클라이언트와 서버라도 연락처에 대한 새로운 프로토콜 공격 표면입니다.
• 어떤 C++/Qt 구현이 사용하기에 충분히 안전한지 불분명

서버/클라이언트 구현

여기의 사용 사례는 매우 최소이기 때문에 Ricochet에서 100% 기능 완전하고 사양 동작 호환 HTTP 클라이언트가 필요하지 않습니다. 버그 가능성을 최대한 낮추기 위해 구현을 _필요한_ 기능으로 제한하고 (예: 청크 전송 인코딩 또는 난해한 옵션을 사용하지 않습니다.) 도움이 되는 경우 Connection: close 강제 실행할 수도 있습니다. 이것은 네트워크에 노출된 코드의 양이 매우 적으며 여전히 일반적으로 다른 클라이언트 및 서버와 호환됩니다.

서버 동작 및 URL 형식

동일한 숨겨진 서비스 아래의 임의 포트에 HTTP 서버를 배치하는 것을 선호합니다. 새로운 서비스를 제공하는 것은 때때로 느리거나 신뢰할 수 없으며 많은 새로운 회로와 구별 가능한 네트워크 활동을 포함합니다. 이것은 또한 피어가 임의의 .onion에 강제로 연결할 수 없도록 하는 동일한 .onion 호스트 이름을 요구할 수 있음을 의미합니다.

서버가 항상 실행 중이면 연락처 및 비 연락처가 언제든지 찾을 수 있지만 이것은 가치가 없어야 합니다. 활성 파일 제안이 있을 때만 서버가 활성인 경우 해당 상태는 포트를 배울 수 있는 연락처 또는 비접촉자가 감지할 수 있습니다.

Ricochet 클라이언트 이외의 다른 것으로 가장할 필요가 없습니다. 유효한 파일 요청이 아닌 올바른 형식의 모든 요청은 일반 404 오류와 함께 거부되어야 합니다.

다운로드 URL에 대해 다음을 제안합니다.

http://[address].onion:[port]/ricochet/fetch/[uniqid]/[filename]

[address] must be the contact's ricochet connection address
[uniqid] is a large (>=128bit) random identifier
[filename] is the URL-encoded original name of the file

Only HTTP is permitted, no HTTPS. We do not want to require a TLS
implementation, and .onion makes it unnecessary.

Clients may refuse transfer URLs without a /ricochet/fetch/ prefix.

파일 URL은 특정 전송과 관련이 있으며 한 번만 사용할 수 있습니다. 재개를 허용하려면 범위 요청이 지원되어야 하며 병렬 다운로드가 허용될 수 있습니다. 서버는 수신자에게 전체 사본이 있다고 생각되면 URL 제공을 중단해야 합니다.

파일 제공 프로토콜

파일 제안을 확장된 채팅 메시지로 패키징할 수 있습니다.

message ChatMessage {
    required string message_text = 1;
    optional uint32 message_id = 2;
    optional int64 time_delta = 3;

    // Indicates a file transfer offer. message_text must begin with a valid
    // file transfer URL, terminated by the first whitespace or end of message.
    // The rest of message_text, if any, should be displayed as a user message
    // along with the file. 
    optional FileInfo file_info = 4;
}

message FileInfo {
    // required
    optional string file_name = 1;
    optional uint64 file_size = 2;
    // optional
    optional string content_type = 3;
}

message ChatAcknowledge {
    optional uint32 message_id = 1;
    optional bool accepted = 2 [default = true];
    optional bool file_received = 3;
    optional bool file_refused = 4;
}

이 메시지의 확인은 파일 제안도 확인합니다. URL에 즉시 액세스하여 파일을 다운로드할 수 있습니다. 메시지를 정상적으로 확인하는 것 외에도 수신자는 전송이 완료되거나 거부된 경우 적절한 필드를 설정하여 추가 ChatAcknowledge 보내야 합니다. 발신자는 이전 클라이언트 또는 대체 다운로더를 지원하기 위해 ChatAcknowledge 에 의존하지 않고 전송된 데이터만을 기반으로 전송이 완료된 것으로 간주할 준비가 되어 있어야 합니다.

이것은 파일 전송을 구현하지 않는 클라이언트와 완전히 호환된다는 깔끔한 속성을 가지고 있습니다. 사용자는 URL을 보고 브라우저에서 다운로드할 수 있습니다. 그러나 이것은 특별히 의미가 없습니다.

XXX 발신자가 취소를 표시하는 방법은 여기에 정의되어 있지 않습니다.

다음 단계

나는 이 일을 꽤 빨리 진행하고 싶기 때문에 곧 프로토콜과 주요 UX 결정을 확정하는 것을 목표로 할 것입니다.

이미 많은 양의 코드가 작성되어 있지만 수정이 필요하고 여기에서 결정한 사항에 따라 변경해야 합니다.

이견있는 사람?

이것은 나에게 좋아 보인다. HTTP 서버 방향이 올바른 방향으로 느껴진다는 데 동의합니다.

특별한 순서나 우선순위 없이 몇 가지 생각:

• 다운로드 시 클라이언트 인증이 없으면 주목할 가치가 있는 공격 벡터가 있습니까? 위협 모델에 중요한 것은 생각할 수 없지만... 참고로 다음은 내 마음을 사로잡은 몇 가지 사항입니다.
  
  
  
  • 공격자가 피해자에게 파일을 제공한 다음 공격자 자신을 가져오거나 여러 사람이 모두 연결 풀을 열어 채우도록 하는 DoS/slowloris 유형 공격의 가능성이 있습니까?
  
  
  • 공격자가 누군가에게 파일을 제공하도록 한 다음 자신이 그렇게 하고 있음을 다른 사람에게 증명할 수 있는 속성 공격이 있습니까?
  
  
• 파일 이름 및 콘텐츠 유형은 #338에서 식별된 것과 동일한 유니코드 문제가 발생하기 쉽습니다.
• 클라이언트는 HTTP 리디렉션 및 HTTP 스트림을 가로채려는 기타 시도를 거부해야 합니다.
• 잘못된 URL은 404가 아니라 연결 닫기를 트리거해야 한다고 주장합니다.

이것은 파일 전송을 구현하지 않는 클라이언트와 완전히 호환된다는 깔끔한 속성을 가지고 있습니다. 사용자는 URL을 보고 브라우저에서 다운로드할 수 있습니다.

• 이것은 ricochet http 클라이언트가 피할 수 있지만 브라우저는 할 수 없는 위에서 언급한 몇 가지 공격 벡터를 엽니다. 링크 열기에 대한 경고가 이미 있지만 파일 전송의 메시징 및 지원되는 기능 상태가 피싱에 대한 균열을 열 수 있는지 궁금합니다.

• 다운로드 시 클라이언트 인증이 없으면 주목할 가치가 있는 공격 벡터가 있습니까? 위협 모델에 중요한 것은 생각할 수 없지만... 참고로 다음은 내 마음을 사로잡은 몇 가지 사항입니다.

뭐, 받는 사람과 파일에 고유한 URL을 사용하여 인증하는 방법이 있습니다. 문제는 전송 가능하다는 것입니다. 이 인증은 발신자 이외의 다른 사람에게 수신자를 식별하지 않으며(비암호화 방식으로) 수신자가 보호하고자 하는 비밀을 포함하지 않습니다.

• 공격자가 피해자에게 파일을 제공한 다음 공격자 자신을 가져오거나 여러 사람이 모두 연결 풀을 열어 채우도록 하는 DoS/slowloris 유형 공격의 가능성이 있습니까?

제공되는 파일당 연결 수를 제한하는 한 DoS 옵션은 없다고 생각합니다. 하나의 파일을 한 사람과 한 번 공유하는 것이 목적이므로(이력서 및 기타 문제 허용) 엄격할 수 있습니다. 또한 사용성을 위해 최소 전송 속도를 설정하는 것이 좋습니다.

• 공격자가 누군가에게 파일을 제공하도록 한 다음 자신이 그렇게 하고 있음을 다른 사람에게 증명할 수 있는 속성 공격이 있습니까?

흥미로운! 나는 이 공격을 좋아한다. 클라이언트 인증을 변경하여 약한 방어가 있지만 실제로는 URL 공유를 권장하지 않습니다. 나는 또한 이러한 URL을 생성한 발신인 이외의 의도된 수신자를 식별하지 않도록 하는 것을 좋아합니다.

실제로 암호화 속성을 제거하려면 임시 서비스에서 파일을 제공해야 합니다. _contact_당 하나의 임시 서비스가 필요한지 여부도 확실하지 않습니다. 기술적으로 Bob은 Alice에게 위험한 파일을 보내도록 설득할 수 있고 Bob은 Carol과 주소를 공유한 다음 Carol은 개별적으로 Alice가 무해한 파일을 보내도록 할 수 있으므로 Carol은 위험한 URL이 Alice로부터 온 것인지 확인할 수 있습니다.

어트리뷰션과 관련하여 가장 안전한 답변은 세션당 연락처별로 고유한 임시 서비스를 사용하는 것입니다. 이에 대한 나의 우려는 1) 서비스 게시 지연입니다. 2) _많은_ 더 많은 회로가 필요합니다. 3) 트래픽 분석에 더 명확하게 나타납니다.

세션의 모든 파일 전송에 하나의 임시 서비스를 사용해도 괜찮을 것 같습니다. 적어도 여전히 암호학적으로 구별되고 이러한 모든 영향을 줄이며 실패하는 경우가 고안되었습니다.

• 파일 이름 및 콘텐츠 유형은 #338에서 식별된 것과 동일한 유니코드 문제가 발생하기 쉽습니다.

콘텐츠 유형은 MIME 유형이므로 유니코드 문제가 없습니다. 파일 이름을 삭제하기 위해 나는 오래 전에 몇 가지 규칙을 생각해 냈으며, 이에 대해서는 좀 더 생각해야 합니다. 거기에 매우 조심해야합니다.

• 클라이언트는 HTTP 리디렉션 및 HTTP 스트림을 가로채려는 기타 시도를 거부해야 합니다.

동의하다.

• 잘못된 URL은 404가 아니라 연결 닫기를 트리거해야 한다고 주장합니다.

아무 반응도 없이? 흠. 이로 인해 ricochet 클라이언트가 네트워크 오류가 있는지 또는 URL이 더 이상 유효하지 않은지 알려주는 것이 약간 더 모호해집니다. 그렇지 않으면 나는 그것에 대해 아무런 문제가 없으며 승인되지 않은 클라이언트에게 아무 것도 보내지 않고 싶습니다.

이것은 파일 전송을 구현하지 않는 클라이언트와 완전히 호환된다는 깔끔한 속성을 가지고 있습니다. 사용자는 URL을 보고 브라우저에서 다운로드할 수 있습니다.

• 이것은 ricochet http 클라이언트가 피할 수 있지만 브라우저는 할 수 없는 위에서 언급한 몇 가지 공격 벡터를 엽니다. 링크 열기에 대한 경고가 이미 있지만 파일 전송의 메시징 및 지원되는 기능 상태가 피싱에 대한 균열을 열 수 있는지 궁금합니다.

여기서 주의사항은 URL을 여는 것과 동일해야 합니다. 나는 이것이 반드시 디자인할 가치가 있는 유스 케이스라고 생각하지 않습니다. 결국에는 계속 남을지 모르겠습니다.

어떤 C++/Qt 구현이 사용하기에 충분히 안전한지 불분명

이 사용 사례에는 이미 너무 크지만 보안을 염두에 두고 작성되었습니다. https://github.com/reyk/httpd

message FileInfo {
    // required
    optional string file_name = 1;
    optional uint64 file_size = 2;
    // optional
    optional string content_type = 3;
}

사용자가 볼 수 있는 파일 이름 확장자와 별도로 추가 콘텐츠 유형을 저장하려는 이유가 궁금합니다. 기술적으로 어떤 프로그램을 시작할지 또는 사용자가 기대하는 것에서 비기술적으로 수신기 측에서 혼란을 일으킬 수 있습니까?

XXX 발신자가 취소를 표시하는 방법은 여기에 정의되어 있지 않습니다.

ChatAcknowledge 메시지의 bool file_refused 플래그가 그렇게 하는 방법이 아닙니까? 아니면 파일이 승인된 후 전송 중을 의미합니까?

잘못된 URL은 404가 아니라 연결 닫기를 트리거해야 한다고 주장합니다.

👍

흥미로운! 나는 이 공격을 좋아한다. 클라이언트 인증을 변경하여 약한 방어가 있지만 실제로는 URL 공유를 권장하지 않습니다. 나는 또한 이러한 URL을 생성한 발신인 이외의 의도된 수신자를 식별하지 않도록 하는 것을 좋아합니다.

클라이언트 호환성을 희생하면서 수신자 공개 키나 세션 ID로 파일 내용을 암호화하는 것이 가능합니까?

사용자가 볼 수 있는 파일 이름 확장자와 별도로 추가 콘텐츠 유형을 저장하려는 이유가 궁금합니다. 기술적으로 어떤 프로그램을 시작할지 또는 사용자가 기대하는 것에서 비기술적으로 수신기 측에서 혼란을 일으킬 수 있습니까?

흠. 두 가지 용도를 염두에 두고 있습니다.

1. 인라인 이미지를 구현할 때 어떤 파일이 이미지인지 알 수 있는 방법이 필요합니다.
2. 일부 파일 형식(이미지/, 비디오/ 등)에 대해 다른 아이콘을 표시할 수 있으면 좋을 것입니다.

확장을 기반으로 이를 감지하는 것은 적어도 (잘못된) 콘텐츠 유형을 갖는 것만큼 신뢰할 수 없습니다. 실제로 실행 파일로 열릴 때 이미지로 표시되지 않도록 #2에 주의가 필요하다는 것이 맞습니다. 그 이유만으로도 콘텐츠 유형을 제거하고 확장자에 의해서만 감지하는 것이 더 나을 수 있습니다. 흠..

XXX 발신자가 취소를 표시하는 방법은 여기에 정의되어 있지 않습니다.

ChatAcknowledge 메시지의 bool file_refused 플래그가 그렇게 하는 방법이 아닙니까? 아니면 파일이 승인된 후 전송 중을 의미합니까?

받은 메시지에 대해 ChatAcknowledge 를 보내는 것만 유효합니다. 자신의 메시지를 확인하는 것은 의미가 없습니다. 따라서 file_refused 는 받는 사람이 취소할 수 있는 방법을 제공하지만 보낸 사람이 "이 파일을 더 이상 제공하지 않습니다"라고 말할 수 있는 동등한 방법을 아직 정의하지 않았습니다.

클라이언트 호환성을 희생하면서 수신자 공개 키나 세션 ID로 파일 내용을 암호화하는 것이 가능합니까?

파일을 암호화한다고 @s-rah의 속성 공격이 해결되지는 않습니다. 이는 URL과 함께 암호 해독 키를 제공해야 한다는 의미일 뿐입니다. 수신자의 공개 키로 암호화하는 일반적인 방법은 일반적으로 파일 데이터에 사용되는 대칭 암호화 키를 래핑하기 때문에 동일한 문제가 있습니다.

보낸 사람이 파일을 제공하고 있음을 입증하기 위해 받는 사람이 신원 개인 키를 포기하도록 요구하는 것이 더 유용할 것입니다. 이를 위해 우리는 파일을 제공하기 전에 수신자의 공개 키로 연결을 인증해야 합니다. 그러나 이것은 HTTP에 잘 매핑되지 않습니다(아니요, TLS 없음). 그것은 다른 프로토콜을 사용하는 것에 찬성하는 포인트가 될 것입니다.

완전히 다른 접근 방식은 수신자가 서버를 호스트하고 발신자가 데이터를 업로드하는 클라이언트 역할을 하도록 하는 것입니다. 이것은 HTTP 또는 다른 것과 함께 작동할 수 있지만 유연성에 몇 가지 단점이 있습니다. 이 경우 귀속 문제는 없을 것입니다.

인라인 이미지를 구현할 때 어떤 파일이 이미지인지 알 수 있는 방법이 필요합니다.

귀하의 이전 진술 I don't trust image decoders 전적으로 동의합니다.

자신의 메시지를 인정하는 것은 의미가 없습니다.

내 나쁜, 실제로 "발신자"라고 표시되는 동안 "수신자"를 읽습니다. :)

보낸 사람이 파일을 제공하고 있음을 입증하기 위해 받는 사람이 신원 개인 키를 포기하도록 요구하는 것이 더 유용할 것입니다. 이를 위해 우리는 파일을 제공하기 전에 수신자의 공개 키로 연결을 인증해야 합니다. 그러나 이것은 HTTP에 잘 매핑되지 않습니다(아니요, TLS 없음).

흥미롭게 들립니다. 이 작업을 수행하는 다른 프로토콜의 예가 있습니까? 또는 어떻게 설정할 수 있습니까? 노이즈 프레임워크는 https://github.com/ricochet-im/ricochet/issues/72#issuecomment -258894126에 언급된 것처럼 여기에서 도움이 될 수 있습니다.

누군가가 이것을 빨리 필요로 한다면, 당신은 리코셰 와 함께

-----PGP 서명 메시지 시작-----
해시: SHA512

존 브룩스:

HTTP만 허용되고 HTTPS는 허용되지 않습니다. 우리는 TLS를 요구하고 싶지 않습니다
구현하고 .onion을 사용하면 필요하지 않습니다.

이것이 Ricochet의 위협 모델의 일부인지 확실하지 않습니다.
그러나 Whonix와 같은 환경에서 Tor 클라이언트는 내용을 읽을 수 있습니다.
.onion 트래픽이 아닌 TLS 트래픽(TLS는
다른 VM).
-----PGP 서명 시작-----

iQIcBAEBCgAGBQJYKlGYAAoJELPy0WV4bWVwu/gQAI/7bmPTKwbcsjEntuEjc03j
nQFKDvSMg05FXR9rljFym5E++pr1FEteKb2qAu0Gub9CbkxCWhibBYNQHi1aFgy5
wgO07yom0oJI4JxBXA185TNSJKE7+LnDAqUCT0H1d0yCy5t4TZfFQHJFLdhOjdk+
GD+Lbuv3pH0GIInsK7iAFQlps0bQmI8aNrNAgoiuk3iWI9MqGFZ8BoXZlabMeGnF
O0OeaibMjtvtuvX4mRsgTFZdNzzUmSfmkoYsABHDK/He4rcnUg6LUetVz16YKzuo
i5Oxy+dQZ6FHHICsQq2Ajg35LfW95I27jcm0QBGFZ08tu3Igt7DFqw9Sq1Ydg5Hl
J/HckRIA5pIJJUcOUa4ynFyk2t/hA0fQEjSoy9C66GnH4Fzt6X/Izs0CDkPkZOQ/
+Vo7wYkqyKcInn2uu7sb62lopX7L6QKHMORiO/5echUMCNCs5fVx7pDenIKvXew
88QcZ/UkR48N9RdKaNC+UdCt3a/vJzQhbzB65cgGuPtvJLhUPFay2IK/szP0/Drw
gPXT+kwbCcBKqbmzkniPysn0Z62wXOlZAfiI/BJ5TqbqILNlhyR9HFSb9MIImiNL
Es+Q3vteUEm6pGVGPnqMZMm2dxVYmP5xx3pHhqq7GjaeGplNEi0ZwTsmSpfCztPB
Y6ksrSAXNDadT0ijrXfu
=TeTg
-----끝 PGP 서명-----

가능한 해결 방법 : 최소한 Windows 및 Linux에는 텍스트 파일로 암호화된 모든 파일을 저장하는 자체 포함 GPG 프로그램인 gpg4usb(gpg4usb.org)가 있습니다.

상호 작용:

출력(메모장에서 _data.docx.asc_ 열기):

함정:

• 끊다? 나는 Ricochet을 통해 매우 긴 텍스트 비트를 보냈지만 어느 시점에서 잘린다고 상상할 수 있습니다. 파일을 청크로 보내야 할 수 있습니다.
• 파일이 원본보다
• GPG를 사용하는 사람은 거의 없으므로( 위의

업데이트: 이 프로그램은 오래된 버전의 GPG를 사용하므로 여전히 해결 방법으로 작동할 수 있지만 최근에 업데이트된 다른 GPG 호환 도구에서는 작동하지 않을 수 있습니다.

1) 파일 전송 기능은 실제 작업 환경에서 필수적입니다. 업무상의 이유로 저는 자주 이동하고 동료와 메시지 및 파일을 교환해야 합니다(드물게 이미지, 대부분의 .docx, xls 및 기타 파일 형식). 물론 우리는 이것이 안전하고 예약된 채널에서 이동하는지 확인해야 합니다.
파일을 의도한 수신자 이외의 다른 사람이 가로채거나 가져갈 수 없도록 하는 것이 절대적으로 중요합니다(n.1 요청).
그래서 저는 어떤 식으로든 볼 수 있거나 쉽게 파생될 수 있는(그리고 다른 사람에게 양도 가능한) 공개 URL(스크램블되거나 이와 유사한 것이 있더라도)의 사용에 대해 절대적으로 반대합니다. 대화 내용과 파일은 보낸 사람과 받는 사람 사이에서 엄격하게 비공개로 유지되어야 합니다(순수한 P2P이며 공유하지 않음).
'공개' URL을 사용하는 경우 수신자 자체에서 오는 경우 고려해야 하는 "공격" 유형입니다.

충성스럽지 않은 직원이 이 메커니즘을 알고 다른 채널(자취를 남기지 않고 두 번째 Ricochet IM 채팅일 수도 있음)을 전달하는 것을 생각해보세요. URL을 받자마자 제3자에게... 제 3자가 파일을 다운로드하고 직원도 파일을 다운로드하고 아무 잘못도 없는 척합니다... 공개/표시/복사 가능한 링크가 없는 시스템에서 채팅 창에서 받는 유일한 옵션은 파일을 다운로드하는 것뿐입니다. 자신의 PC를 거부하거나 해당 파일에 액세스할 수 있는 유일한 다른 사람(보낸 사람 제외)이며 유출된 경우 '공개 http URL....

2) 이미 작동하고 있는 아이디어를 얻기 위해 P2P 파일 전송을 제공하는 다른 채팅 솔루션을 본 적이 있습니까?
이 옵션이 나타날 때까지 기다리는 동안 우리는 현장에서 QTox를 사용하고 있으며 채팅에 완전히 포함된 작동하고 멋진 파일 전송 옵션이 있습니다.
(과거에는 uVNC도 사용했으며 p2p 보안 터널을 통해 쉽게 파일을 전송했습니다)

3) 내 예전 스타일의 직감은 http 프로토콜에 대한 아이디어를 버리고 기존의 감사되고 안전하며 신뢰할 수 있는 ricochet 프로토콜로 파일의 효율적인 패킷화 작업을 시작하는 것입니다(필요한 작은 수정 및 선택적 추가 단순 암호화 레이어 포함) , 첫 번째 옵션에 설명된 대로.
단순히 Mime64+a 라이트 스크램블링으로 파일을 래핑하는 것만으로도 래퍼로 충분합니다.
나는 더 멋지고 빠른 전송 메커니즘보다 내 파일이 경쟁자의 손에 들어갈 위험이 없는 보안과 확실성을 선호합니다.

4) 대부분의 사람들이 여전히 이메일(첨부 파일의 MIME-64 암호화되지 않은 인코딩)을 사용하여 파일을 전송한다는 사실을 잊지 마십시오. 느리고 비효율적이며 확실히 안전하지 않습니다.
최고 속도는 실제 모바일 환경에서 전송의 중요한 부분이 아닙니다(그리고 원격으로 사용되는 일부 모바일 연결은 어쨌든 엄청난 속도를 지원할 수조차 없습니다...).
나에게는 동료에 대한 전송 상태 표시기가 있고, 긴 파일 전송을 '일시 중지/재개'할 수 있는 가능성과 연결 끊김을 처리하는 메커니즘을 갖는 것이 더 중요합니다. 필드) 진행 중인 전송과 함께.

@nogoest의 Onionize ( Golang 으로 작성)라는 작고 가벼운 Tor Hidden Service 기반 파일 공유 응용 프로그램이 있습니다.

좋은 메신저 + 파일 공유 자손을 만들 가능성이 있는지 궁금합니다 ;)