Retour à l'accueil

Proxy MTProto : secrets personnels et politiques

L'article décrit l'implémentation de proxies MTProto personnels sur Erlang avec des domaines SNI uniques. Il couvre le système de politiques pour le contrôle d'accès, les limites de connexions et l'analyse des utilisateurs. Des exemples de configuration et de code sont fournis.

Proxies MTProto Personnels : Erlang et Politique d'Accès
Advertisement 728x90

Proxies MTProto personnels sur Erlang : Système de politiques et secrets uniques

Les proxies MTProto permettent d'accéder à Telegram malgré la censure. Le modèle traditionnel utilise une seule clé secrète pour tous les utilisateurs, ce qui pose des problèmes : absence de contrôle d'accès, impossibilité d'analyser l'activité des utilisateurs et monétisation limitée. La solution consiste en des secrets personnels avec un domaine SNI unique pour chaque client, implémentée dans Erlang mtproto_proxy via un système de politiques.

Cette implémentation est évolutive grâce à une validation des connexions en O(1) et des règles configurables à l'exécution. Elle prend en charge les limites de connexion, la révocation d'accès et le suivi d'activité sans redémarrage du serveur.

Avantages d'Erlang pour les proxies à haute charge

Erlang/OTP est idéal pour les proxies MTProto grâce à son architecture conçue pour des millions de connexions de longue durée :

Google AdInline article slot
  • Isolation des processus : Chaque connexion est un processus léger distinct (~2 Ko). Un plantage dans l'un n'affecte pas les autres.
  • Mise à l'échelle automatique : BEAM répartit les processus sur tous les cœurs du CPU sans gestion manuelle.
  • Multitâche préemptif : Aucun client ne peut monopoliser un cœur.
  • Syntaxe binaire pour l'analyse : Analyse sécurisée du TLS ClientHello en une ligne :
parse_client_hello(
  <<?TLS_REC_HANDSHAKE, ?TLS_10_VERSION, TlsFrameLen:16,
    ?TLS_TAG_CLIENT_HELLO, HelloLen:24, ?TLS_12_VERSION,
    Random:32/binary,
    SessIdLen, SessId:SessIdLen/binary,
    CipherSuitesLen:16, CipherSuites:CipherSuitesLen/binary,
    CompMethodsLen, CompMethods:CompMethodsLen/binary,
    ExtensionsLen:16, Extensions:ExtensionsLen/binary>>
) when TlsFrameLen >= 512, HelloLen >= 508 -> ...
  • Surveillance en direct : Console distante pour inspecter les tables et les états.
  • Mises à jour à chaud : Modification du code et de la configuration sans interrompre les connexions.

Le volume total de code est de 3500 lignes, moins que la plupart des alternatives.

Format SNI et secret Fake-TLS

Server Name Indication (SNI) permet à un client de spécifier un domaine dans ClientHello avant de terminer la poignée de main TLS. Fake-TLS imite TLS 1.3 ClientHello avec un SNI légitime, masquant MTProto dans des champs chiffrés.

Format du secret personnel :

Google AdInline article slot
0xEE | <16 octets aléatoires> | <domaine SNI en UTF-8>

Chaîne hexadécimale pour t.me/proxy :

ee<32 caractères hexadécimaux><SNI encodé en hexadécimal>

Validation : HMAC ClientHello avec un secret de base (un par port). L'unicité est basée sur le domaine SNI de l'extension.

Système de politiques : Règles d'accès

Les politiques sont une liste ordonnée de règles pour chaque connexion. La première règle non satisfaite rejette la connexion.

Google AdInline article slot

Types de règles

| Règle | Description |

|------|-------------|

| {in_table, Key, Table} | La clé est dans la table |

| {not_in_table, Key, Table} | La clé n'est pas dans la table |

| {max_connections, [Key,...], N} | Connexions par clés ≤ N |

Clés issues de la connexion

  • tls_domain — SNI du fake-TLS
  • port_name — nom du port
  • client_ipv4/client_ipv6 — IP du client
  • {client_ipv4_subnet, Mask} — sous-réseau

Les tables sont des tables de hachage en mémoire, sauvegardées lors du rechargement de la configuration, perdues au redémarrage.

Politique pour les proxies personnels

Politique de base :

{policy, [
  {in_table, tls_domain, personal_domains},
  {max_connections, [tls_domain], 30}
]}
  • Liste blanche : tls_domain dans personal_domains.
  • Limite : ≤30 connexions simultanées par domaine (empêche le partage de lien).

Ajouts :

{max_connections, [client_ipv4], 30},
{not_in_table, client_ipv4, ip4_blacklist}

Lancement d'un proxy personnel standard

sys.config

{mtproto_proxy, [
  {ports, [
    #{name => mtp_handler,
      listen_ip => "0.0.0.0",
      port => 443,
      secret => <<"d0d6e111bada5511fcce9584deadbeef">>,
      tag => <<"dcbe8f1493fa4cd9ab300891c0b5b326">>}
  ]},
  {allowed_protocols, [mtp_fake_tls]},
  {policy, [
    {in_table, tls_domain, personal_domains},
    {max_connections, [tls_domain], 100}
  ]}
]}

Enregistrement du domaine

mtp_proxy eval '
  mtp_policy_table:add(personal_domains, tls_domain, "alice42.example.com").'

Le domaine est activé instantanément.

Points clés

  • Les domaines SNI personnels permettent le contrôle d'accès et l'analyse sans changer le secret de base.
  • Les politiques sont vérifiées en O(1), évoluant jusqu'à des milliers d'utilisateurs.
  • Erlang garantit l'isolation des connexions et un temps d'arrêt nul.
  • Les tables de politiques sont gérées à l'exécution via Erlang RPC.
  • Une limite de 30 connexions par domaine empêche les abus.

— Editorial Team

Advertisement 728x90

Lire ensuite