Ricochet: Transferencias de archivos

Vaya, este es un problema antiguo. Ya es hora de hacer esto. Hablemos de transferencias de archivos. Esto es en parte solicitar comentarios, en parte tratar de convencerme a mí mismo, y en parte es una pérdida de ideas, pero espero que sea útil.

UX

Veo dos tipos amplios de casos de uso para transferencias de archivos. Los usuarios activos envían y reciben archivos durante las conversaciones y esperan que el archivo forme parte de su conversación. Las caídas de archivos son para una minoría importante de usuarios de Ricochet que desean permanecer en línea y poder recibir archivos en cualquier momento, incluso si no están activos de inmediato.

Como la mayoría de las aplicaciones de mensajería, queremos realizar transferencias de archivos en línea como parte de la conversación y no deben requerir el uso de ninguna otra aplicación (incluido un navegador).

Arrastrar y soltar un archivo en una conversación es la forma normal de enviar un archivo. Podría decirse que podría ser fácil enviar accidentalmente un archivo de esta manera. Eso podría mitigarse colocando el archivo en el cuadro de cuenta regresiva antes de enviarlo . Debería haber otro método de interfaz de usuario visible para enviar archivos, como un botón en el encabezado de la conversación o cerca de la entrada del mensaje.

Los archivos ofrecidos deben caducar después de un tiempo suficiente para asumir razonablemente que el usuario podría haberlo olvidado.

El modelo de amenazas de Ricochet prohíbe almacenar datos de conversaciones (incluidos archivos) automáticamente. El modelo de amenazas también ve a los contactos como posibles adversarios de explotación, por lo que queremos reducir el conjunto de acciones que un contacto puede desencadenar sin la aprobación del usuario. Estos sugieren que deberíamos exigir la aceptación explícita de forma predeterminada para las transferencias de archivos. El usuario tiene que elegir explícitamente dónde guardar cada archivo, a menos que configure una ubicación predeterminada. Esto está bien con el caso de uso del usuario activo, pero para la caída de archivos, necesitaremos una opción para guardar archivos automáticamente (que también podría ser por contacto).

Las ofertas o transferencias activas deben ser fácilmente notorias para ambas partes. Además de mostrar el progreso de la transferencia en la conversación , debe haber un progreso en el encabezado de la el estado de la transferencia global en algún lugar. Esto es particularmente importante porque la conversación puede continuar mientras se realizan las transferencias. Cuando finaliza una transferencia, se debe mover al final de la conversación.

Las transferencias completadas se abren haciendo clic , con una advertencia similar a la advertencia del navegador.

Se sabe que Tor no es confiable, por lo que la capacidad de reanudar será importante. Debemos reconectarnos y reanudarnos automáticamente siempre que sea posible. Si ha pasado demasiado tiempo, o uno de los clientes ha perdido su historial, la reanudación aún debería ser posible guardando un archivo incompleto existente .

UX futuro

La visualización de imágenes en línea con las conversaciones es una función de mensajería estándar. Esto es fácil de hacer una vez que tenemos la transferencia de archivos en su lugar, excepto que no confío en los decodificadores de imágenes . Una vez que encontremos un decodificador robusto y seguro para la memoria, o un sandboxing estilo seccomp multiplataforma, vale la pena hacerlo.

Alguien señaló que podríamos obtener archivos previamente , al menos creando conexiones y almacenando en búfer hasta cierto límite en la memoria, para que el proceso de transferencia parezca más rápido.

Sería bueno permitir la transferencia de lotes de archivos o carpetas enteras hasta un límite razonable.

Tener una forma de verificar automáticamente

Protocolo

Conexiones

Los datos de archivo no se pueden enviar a través de la conexión de protocolo principal de Ricochet. A pesar de que empaquetamos datos, debido a las propiedades de almacenamiento en búfer para los flujos de Tor, grandes cantidades de datos estarán en las colas cuando se inunde una conexión de servicio oculta. Esto provoca una latencia extrema (a menudo de 30 segundos o más) para esa transmisión. Cualquier otra forma de control de velocidad tendría demasiado impacto en las velocidades de transferencia.

La respuesta simple es abrir conexiones adicionales al servicio del par. Tor multiplexará estas conexiones en el mismo circuito, pero el comportamiento de almacenamiento en búfer es significativamente mejor. En las pruebas casuales, no parece haber un impacto significativo en la latencia de los mensajes cuando se transfieren datos a otra secuencia en el mismo circuito.

También podríamos usar opciones de aislamiento de circuitos para obligar a Tor a construir nuevos circuitos para transferencias. No está claro si esto sería útil para el rendimiento o la latencia, y no está claro si la construcción de circuitos simultáneos adicionales tendría un impacto significativo en el anonimato o el análisis del tráfico.

El protocolo de Ricochet no permite más de una conexión autenticada por contacto, porque sería ambiguo qué conexión debería usarse y podría violar las expectativas sobre el orden de los mensajes. Si las conexiones adicionales usan el protocolo de Ricochet, deberán autenticarse de manera diferente para indicar que la conexión solo se usa para la transferencia de datos.

Debido a que la transferencia de datos se realiza a través de conexiones secundarias, no estamos obligados a empaquetar datos con el protocolo de Ricochet. Vale la pena pensar en las opciones aquí.

Opción 1: protocolo Ricochet modificado

Mi idea original era utilizar el protocolo de Ricochet para la transferencia de datos de archivos en conexiones adicionales. Esto no es del todo sencillo.

Beneficios:

• Podría enviar fácilmente archivos pequeños en línea a través de la conexión de protocolo
• Más coherente con el protocolo existente
• No hay nuevas superficies de ataque de analizador / servidor

Desventajas:

• Solo puede haber una conexión principal, por lo que la autenticación termina siendo extraña
• A menos que hagamos modificaciones de protocolo más profundas, los datos deben dividirse en fragmentos de 65 kb con encabezados.
• El diseño y la implementación del protocolo es difícil de acertar

Hay un trabajo anterior sobre cómo podría verse esto desde una rama WIP en FileTransferChannel.proto y FileTransferDataChannel.proto .

Opción 2: HTTP (mi preferencia actual)

Los clientes de Ricochet podrían ofrecer archivos a través de HTTP, utilizando un servidor interno simple y URL únicas, similar a OnionShare . Ese servidor podría estar en un puerto diferente (posiblemente aleatorio) del mismo servicio oculto, en nuevos servicios efímeros o incluso compartir el mismo puerto mediante la detección de protocolo.

Beneficios:

• Implementación más robusta / estándar / preparada para el futuro
• Compatibilidad con versiones anteriores del destinatario: puede recurrir de forma natural a mostrar una URL
• Posible para los destinatarios descargar usando navegadores y otras herramientas
• También se puede utilizar para ofrecer archivos a personas que no son contactos.

Desventajas:

• Incluso un cliente y un servidor HTTP mínimos son una nueva superficie de ataque de protocolo para los contactos.
• No está claro qué implementación de C ++ / Qt sería lo suficientemente segura para usar

Implementación servidor / cliente

No hay necesidad de un cliente HTTP 100% completo y compatible con el comportamiento de las especificaciones en Ricochet, porque el caso de uso aquí es mínimo. Para mantener el potencial de errores lo más bajo posible, limitaría la implementación a las características que _necesitamos_, y no usaría (por ejemplo) codificación de transferencia fragmentada o opciones esotéricas. Incluso podríamos forzar Connection: close si es útil. Esto termina siendo una cantidad bastante pequeña de código expuesto a la red y, en general, sigue siendo compatible con otros clientes y servidores.

Comportamiento del servidor y formato de URL

Yo prefiero poner el servidor HTTP en un puerto aleatorio bajo el mismo servicio oculto. La creación de nuevos servicios a veces es lenta o poco confiable e implica muchos circuitos nuevos y una actividad de red distinguible. Esto también significa que podemos requerir el mismo nombre de host .onion, lo que evita que los pares puedan forzar una conexión a un .onion arbitrario.

Si el servidor está siempre en ejecución, es posible que los contactos y los no contactos lo encuentren en cualquier momento, aunque esto no debería tener ningún valor. Si el servidor solo está activo cuando hay ofertas de archivos activos, ese estado puede ser detectable para los contactos o no contactos que pueden conocer el puerto.

No tiene sentido ni necesidad de tratar de disfrazarse como otra cosa que no sea un cliente de Ricochet. Todas las solicitudes bien formadas que no sean solicitudes de archivo válidas deben rechazarse con un error 404 genérico.

Propongo lo siguiente para las URL de descarga:

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.

Las URL de archivo están relacionadas con una transferencia específica y están diseñadas para un solo uso. Las solicitudes de rango deben ser compatibles para permitir la reanudación y pueden permitirse para la descarga paralela. Los servidores deben dejar de ofrecer una URL una vez que crean que el destinatario tiene una copia completa.

Protocolo de oferta de archivos

Podemos empaquetar una oferta de archivo en un mensaje de chat extendido:

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;
}

El reconocimiento de este mensaje también reconoce la oferta del archivo. Se puede acceder inmediatamente a la URL para descargar el archivo. Además de reconocer el mensaje normalmente, el destinatario debe enviar ChatAcknowledge adicionales cuando la transferencia se haya completado o si se rechaza, con el campo apropiado configurado. Los remitentes deben estar preparados para considerar una transferencia completa basada solo en los datos transferidos y no depender de ChatAcknowledge , para respaldar a clientes más antiguos o descargadores alternativos.

Esto tiene la gran propiedad de ser totalmente compatible con clientes que no implementan transferencias de archivos; el usuario verá la URL y podrá descargarla en un navegador. Sin embargo, esto no es especialmente significativo.

XXX No hay forma definida aquí para que el remitente indique la cancelación

Próximos pasos

Me gustaría avanzar en esto con bastante rapidez, así que apuntaré a concretar el protocolo y las principales decisiones de UX muy pronto.

Ya hay una buena parte del código escrito, pero necesita algunas correcciones y necesitará cambios basados ​​en las decisiones aquí.

¿Alguna idea?

Esto se ve bien para mí. Estoy de acuerdo en que la dirección del servidor HTTP parece la correcta.

Un par de pensamientos, sin ningún orden ni prioridad en particular:

• Sin la autenticación del cliente en la descarga, ¿hay algún tipo de ataque que valga la pena destacar? No puedo pensar en ninguno que sea crítico para el modelo de amenazas ... pero para que conste, aquí hay algunas cosas que se me pasaron por la mente:
  
  
  
  • ¿Existe la posibilidad de un ataque de tipo DoS / slowloris en el que un atacante consigue que una víctima entregue un archivo y luego el atacante mismo, o con varias personas abiertas y llenando el grupo de conexiones?
  
  
  • ¿Existe un ataque de atribución en el que un atacante consigue que alguien entregue un archivo y luego pueda demostrarle a otra persona que lo está haciendo?
  
  
• Es probable que el nombre de archivo y el tipo de contenido sean propensos a los mismos problemas de Unicode identificados en el n. ° 338
• Los clientes deben rechazar los redireccionamientos HTTP y otros intentos de secuestrar el flujo HTTP.
• Creo que diría que las URL no válidas deberían simplemente activar el cierre de la conexión, en lugar de un 404.

Esto tiene la gran propiedad de ser totalmente compatible con clientes que no implementan transferencias de archivos; el usuario verá la URL y podrá descargarla en un navegador.

• Esto abre algunos vectores de ataque mencionados anteriormente que el cliente http de rebote puede evitar, pero un navegador no. Ya hay advertencias sobre la apertura de enlaces, pero me pregunto si la mensajería y el estado de las funciones admitidas de las transferencias de archivos podrían abrir una brecha para el phishing.

• Sin la autenticación del cliente en la descarga, ¿hay algún tipo de ataque que valga la pena destacar? No puedo pensar en ninguno que sea crítico para el modelo de amenazas ... pero para que conste, aquí hay algunas cosas que se me pasaron por la mente:

Bueno, existe la autenticación mediante el uso de una URL única para el destinatario y el archivo. La preocupación es que es transferible: esta autenticación no identifica al destinatario ante nadie más que el remitente (y eso no criptográficamente), y no contiene ningún secreto que el destinatario desee proteger.

• ¿Existe la posibilidad de un ataque de tipo DoS / slowloris en el que un atacante consigue que una víctima entregue un archivo y luego el atacante mismo, o con varias personas abiertas y llenando el grupo de conexiones?

Creo que no hay una opción DoS, siempre que limitemos la cantidad de conexiones por archivo ofrecido. Dado que la intención es compartir un archivo con una persona una vez (permitiendo el currículum vitae y otros problemas), podemos ser estrictos al respecto. También podría ser una buena idea establecer una tasa de transferencia mínima, también para la usabilidad.

• ¿Existe un ataque de atribución en el que un atacante consigue que alguien entregue un archivo y luego pueda demostrarle a otra persona que lo está haciendo?

¡Interesante! Me gusta este ataque. Existen defensas débiles al cambiar la autenticación del cliente, pero en realidad solo desalientan el intercambio de URL. También me gusta que estas URL no identifiquen al destinatario previsto más que al remitente que las generó.

Para eliminar realmente la atribución criptográfica, tendríamos que entregar archivos en servicios efímeros. No estoy seguro de si también requiere un servicio efímero por _contacto_. Técnicamente, Bob puede convencer a Alice de que envíe un archivo peligroso, Bob comparte la dirección con Carol, y luego Carol puede hacer que Alice envíe por separado un archivo inocuo, para que Carol pueda confirmar que la URL peligrosa proviene de Alice.

La respuesta más segura en cuanto a atribución sería utilizar un servicio efímero único por contacto por sesión. Mis preocupaciones con esto son 1) latencia de publicación del servicio; 2) _muchos_ circuitos más necesarios; 3) se muestra más claramente en el análisis de tráfico.

Creo que podría estar de acuerdo con el uso de un servicio efímero para todas las transferencias de archivos en una sesión. Al menos sigue siendo criptográficamente distinto, reduce todos esos impactos y el caso en el que falla es artificial.

• Es probable que el nombre de archivo y el tipo de contenido sean propensos a los mismos problemas de Unicode identificados en el n. ° 338

El tipo de contenido es un tipo MIME, por lo que no hay problemas de Unicode. Para desinfectar nombres de archivos, se me ocurrieron algunas reglas hace mucho tiempo, que necesitarán un poco más de reflexión. Hay que tener mucho cuidado ahí.

• Los clientes deben rechazar los redireccionamientos HTTP y otros intentos de secuestrar el flujo HTTP.

De acuerdo.

• Creo que diría que las URL no válidas deberían simplemente activar el cierre de la conexión, en lugar de un 404.

¿Sin respuesta? Mmm. Esto hace que sea un poco más ambiguo para un cliente de rebote saber si hubo una falla en la red o si una URL ya no es válida. De lo contrario, no tengo ningún problema con eso y no me gustaría enviar nada a clientes no autorizados.

Esto tiene la gran propiedad de ser totalmente compatible con clientes que no implementan transferencias de archivos; el usuario verá la URL y podrá descargarla en un navegador.

• Esto abre algunos vectores de ataque mencionados anteriormente que el cliente http de rebote puede evitar, pero un navegador no. Ya hay advertencias sobre la apertura de enlaces, pero me pregunto si la mensajería y el estado de las funciones admitidas de las transferencias de archivos podrían abrir una brecha para el phishing.

Las precauciones aquí tendrían que ser las mismas que para abrir cualquier URL. No creo que este sea necesariamente un caso de uso para el que valga la pena diseñar; no estoy seguro de que termine permaneciendo.

No está claro qué implementación de C ++ / Qt sería lo suficientemente segura para usar

Posiblemente ya sea demasiado grande para este caso de uso, pero escrito teniendo en cuenta la seguridad: https://github.com/reyk/httpd

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

Me pregunto por qué querría guardar un tipo de contenido adicional además de una extensión de nombre de archivo visible para el usuario. ¿Podría eso generar confusión en el lado del receptor, ya sea técnicamente en qué programa comenzar, o no técnicamente en lo que espera un usuario?

XXX No hay forma definida aquí para que el remitente indique la cancelación

¿No es la bandera bool file_refused en el mensaje ChatAcknowledge una forma de hacer eso? ¿O te refieres después de que se haya aceptado un archivo y mientras se realiza la transferencia?

Creo que diría que las URL no válidas deberían simplemente activar el cierre de la conexión, en lugar de un 404.

👍

¡Interesante! Me gusta este ataque. Existen defensas débiles al cambiar la autenticación del cliente, pero en realidad solo desalientan el intercambio de URL. También me gusta que estas URL no identifiquen al destinatario previsto más que al remitente que las generó.

A costa de la compatibilidad del cliente, ¿sería factible cifrar el contenido del archivo con la clave pública del destinatario o algo así como una identificación de sesión?

Me pregunto por qué querría guardar un tipo de contenido adicional además de una extensión de nombre de archivo visible para el usuario. ¿Podría eso generar confusión en el lado del receptor, ya sea técnicamente en qué programa comenzar, o no técnicamente en lo que espera un usuario?

Mmm. Tengo dos usos en mente:

1. Cuando implementemos imágenes en línea, necesitaremos una forma de saber qué archivos son imágenes
2. Sería bueno poder mostrar un ícono diferente para algunos tipos de archivos (imagen /, video /, etc.)

Detectarlos en función de la extensión es al menos tan poco confiable como tener un tipo de contenido (posiblemente incorrecto). Tienes razón en que habría que tener cuidado con el n. ° 2 para asegurarnos de que no mostramos algo como una imagen cuando realmente se abrirá como un ejecutable. Solo por esa razón, tal vez sea mejor eliminar el tipo de contenido y solo detectar por extensión. Mmm..

XXX No hay forma definida aquí para que el remitente indique la cancelación

¿No es la bandera bool file_refused en el mensaje ChatAcknowledge una forma de hacer eso? ¿O te refieres después de que se haya aceptado un archivo y mientras se realiza la transferencia?

Solo es válido enviar ChatAcknowledge para los mensajes que ha recibido; no tiene sentido reconocer sus propios mensajes. Entonces file_refused proporciona una forma para que el destinatario cancele, pero no definí un equivalente para que el remitente diga "Ya no estoy ofreciendo este archivo" todavía.

A costa de la compatibilidad del cliente, ¿sería factible cifrar el contenido del archivo con la clave pública del destinatario o algo así como una identificación de sesión?

Cifrar el archivo no resuelve el ataque de atribución de @ s-rah: solo significa que debe proporcionar una clave de descifrado junto con la URL. Las formas comunes de cifrar la clave pública del destinatario tienen el mismo problema, porque generalmente solo está ajustando la clave de cifrado simétrica utilizada para los datos del archivo.

Sería más útil exigir al destinatario que entregue su clave privada de identidad para demostrar que el remitente está ofreciendo un archivo. Para eso, solo necesitamos autenticar la conexión con la clave pública del destinatario antes de entregar los archivos, pero esto no se asigna bien a HTTP (no, no TLS). Eso sería un punto a favor de utilizar otro protocolo.

Un enfoque completamente diferente es que el destinatario aloje el servidor, y que el remitente actúe como cliente para cargar los datos. Esto podría funcionar con HTTP o cualquier otra cosa, pero tiene algunas desventajas en cuanto a flexibilidad. En ese caso, no habría ningún problema de atribución.

Cuando implementemos imágenes en línea, necesitaremos una forma de saber qué archivos son imágenes

Me gustaría expresar que estoy totalmente de acuerdo con su declaración anterior: I don't trust image decoders .

no tiene sentido reconocer sus propios mensajes.

Mi mal, leí "receptor" mientras que en realidad dice "remitente" :)

Sería más útil exigir al destinatario que entregue su clave privada de identidad para demostrar que el remitente está ofreciendo un archivo. Para eso, solo necesitamos autenticar la conexión con la clave pública del destinatario antes de entregar los archivos, pero esto no se asigna bien a HTTP (no, no TLS).

Suena interesante, ¿tiene ejemplos de otros protocolos que hacen esto? ¿O cómo podría configurarse? Supongo que el marco de Noise podría ayudar aquí como se indica en https://github.com/ricochet-im/ricochet/issues/72#issuecomment -258894126.

Si alguien necesita esto lo antes posible, entonces debe usar onionshare junto con rebote.

----- COMIENCE EL MENSAJE FIRMADO POR PGP -----
Hash: SHA512

John Brooks:

Solo se permite HTTP, no HTTPS. No queremos exigir un TLS
implementación, y .onion lo hace innecesario.

No me queda claro si esto es parte del modelo de amenazas de Ricochet,
pero en entornos como Whonix, el cliente Tor puede leer el contenido
del tráfico .onion pero no del tráfico TLS (ya que el TLS se descifra en un
diferente VM).
----- COMENZAR FIRMA PGP -----

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

Posible solución : al menos en Windows y Linux hay gpg4usb (gpg4usb.org), un programa GPG autónomo que guarda todos los archivos cifrados como archivos de texto:

Interfaz:

Salida (abra _data.docx.asc_ en el bloc de notas):

Trampas:

• ¿Cortar? Envié algunos bits de texto MUY largos a través de Ricochet, pero puedo imaginar que los trunca en algún momento. Es posible que deba enviar archivos en trozos.
• Los archivos son un poco más grandes que los originales (el cifrado aumenta el tamaño y el texto es menos eficiente que el binario)
• Pocas personas usan GPG (excluyendo @JeremyRand arriba), por lo que se

Actualización: este programa utiliza una versión desactualizada de GPG, por lo que, si bien es probable que todavía funcione como solución alternativa, es posible que no funcione con otras herramientas compatibles con GPG recientemente actualizadas.

1) La función de transferencia de archivos es esencial en un entorno de trabajo real. Por motivos laborales, a menudo soy móvil y tengo que intercambiar mensajes y archivos con colegas (rara vez imágenes, la mayoría de archivos .docx, xls y otros tipos de archivos). Por supuesto, debemos asegurarnos de que estos se muevan en un canal seguro y RESERVADO.
Es absolutamente imperativo (solicitud n. ° 1) que el archivo no pueda ser interceptado o tomado por nadie más que el destinatario previsto.
Así que estoy definitivamente y totalmente en contra de cualquier uso de URL públicas (incluso si están codificadas o algo así) que sean visibles de alguna manera, o fácilmente derivables (y transferibles a otros). El contenido de la conversación, así como el archivo, deben permanecer estrictamente privados entre el remitente y el receptor (P2P puro y no compartir en absoluto).
Un tipo de "ataque" que debe considerar si el uso de URL "públicas" proviene del propio receptor.

Piense en un empleado no tan leal que conoce este mecanismo y pasa a un canal diferente (tal vez incluso un segundo chat IM de Ricochet sin dejar ningún rastro ...) la URL a un tercero tan pronto como la recibe ... El tercero descarga el archivo, el empleado también lo descarga y finge no haber hecho nada malo ... En un sistema sin enlaces públicos / visibles / copiables, en el que la única opción que recibe en la ventana de chat es descargar el archivo a su PC o rechazarlo, él es la única otra persona (aparte del remitente) que tiene acceso a ese archivo y si se filtra, entonces no hay excusa de que se deba a una 'URL http pública ...

2) ¿Ha mirado otras soluciones de chat que ofrecen transferencia de archivos P2P para tener ideas de algo que ya funciona?
Mientras esperamos que aparezca esta opción, estamos usando QTox en el campo y tiene una buena opción de transferencia de archivos que funciona y está completamente integrada en el chat.
(en el pasado, también he usado uVNC e hizo transferencias de archivos fáciles a través de túneles seguros p2p)

3) Mi instinto de estilo antiguo sería deshacerme de cualquier idea del protocolo http y comenzar a trabajar en la empaquetado eficiente de archivos en el protocolo de rebote auditado, seguro y confiable existente (con las pequeñas modificaciones necesarias y tal vez una capa adicional opcional de cifrado simple) , como se describe en su primera opción.
Incluso simplemente envolver el archivo con Mime64 + una codificación lite (y hacer lo contrario en la recepción) sería suficiente como envoltorio.
Prefiero la seguridad y la certeza de que no hay riesgos de que mis archivos caigan en manos de la competencia en lugar de un mecanismo de transferencia más elegante y / o más rápido.

4) No olvide que la mayoría de la gente todavía usa el correo electrónico (codificación no cifrada MIME-64 de archivos adjuntos) para enviar archivos ... lento, ineficiente y definitivamente no seguro.
La velocidad máxima no es la parte crítica de la transferencia en un entorno móvil del mundo real (y algunas conexiones móviles utilizadas de forma remota ni siquiera son capaces de soportar velocidades enormes ...).
Para mí es más crítico tener un indicador del estado de la transferencia a mis pares, tener la posibilidad de 'pausar / reanudar' el envío de archivos largos y tener un mecanismo que maneje las conexiones perdidas (lo cual ocurre mucho en el campo) con transferencias en curso.

Hay una pequeña y liviana aplicación para compartir archivos basada en Tor Hidden Service llamada Onionize de @nogoest (escrita en Golang).

Tengo curiosidad por saber si existe la posibilidad de hacer una buena descendencia para compartir archivos de IM +;)