|
|
@@ -38,6 +38,33 @@ goal: to give a possibility to connect to Telegram in a restricted,
|
|
38
|
38
|
censored environment. But it does it slightly differently in details
|
|
39
|
39
|
that probably matter.
|
|
40
|
40
|
|
|
|
41
|
+* **Domain fronting**
|
|
|
42
|
+
|
|
|
43
|
+For years mtg supports domain fronting. This technique means that it fallbacks
|
|
|
44
|
+to accessing a real website in case if request fails. It could fail by many
|
|
|
45
|
+reasons: anti-replay protection, accidental access to the webserver or
|
|
|
46
|
+stale request. Anyway, if mtg rejects this request, it does not break a
|
|
|
47
|
+connection. It connects to the websites and replicates everything that client
|
|
|
48
|
+has sent, and simply proxies it back as is. Users will see a response from
|
|
|
49
|
+the real website, _byte-to-byte identical_ to the response of the real netloc.
|
|
|
50
|
+
|
|
|
51
|
+* **Doppelganger**
|
|
|
52
|
+
|
|
|
53
|
+mtg also is a doppelganger of the website it fronts. Sure, with domain fronting
|
|
|
54
|
+users will see replies of the real website in case if something will go wrong.
|
|
|
55
|
+But what about such cases when _everything is fine_?
|
|
|
56
|
+
|
|
|
57
|
+In that case mtg mimics TLS connection statistical characteristics as close as
|
|
|
58
|
+possible. Different application have different statistics of their patterns.
|
|
|
59
|
+Big CDN steadily pumping the data, small websites burst with short easily
|
|
|
60
|
+compressiable chunks of traffic.
|
|
|
61
|
+
|
|
|
62
|
+mtg artificially emulates those delays to be statistically indistinguishable
|
|
|
63
|
+from the real website even if it covers connection of the very specific app.
|
|
|
64
|
+It also follows 2 most common patterns of traffic chunking, so censors
|
|
|
65
|
+will have to put more resources to find out that we have Telegram here
|
|
|
66
|
+but not a hookah webshop served by nginx.
|
|
|
67
|
+
|
|
41
|
68
|
* **Resource-efficient**
|
|
42
|
69
|
|
|
43
|
70
|
It has to be resource-efficient. It does not mean that you will see
|
|
|
@@ -398,6 +425,55 @@ or if you are using docker:
|
|
398
|
425
|
$ docker exec mtg-proxy /mtg access /config.toml
|
|
399
|
426
|
```
|
|
400
|
427
|
|
|
|
428
|
+## Doppelganger
|
|
|
429
|
+
|
|
|
430
|
+mtg can mimic real websites, please take a look at relevant section in example
|
|
|
431
|
+config file.
|
|
|
432
|
+
|
|
|
433
|
+mtg comes with some very good precollected statistics coming from
|
|
|
434
|
+[ok.ru](https://ok.ru/). It does not mean that you have to cover yourself
|
|
|
435
|
+by pretending that mtg is _ok.ru_. **Do not do that: ok.ru comes from very specific
|
|
|
436
|
+ASNs, but not from VPS providers you are going to use.** What I want to say
|
|
|
437
|
+is that defaults are very good enough to use as is because ok.ru for public
|
|
|
438
|
+pages has a very generic profile of TLS packets delay.
|
|
|
439
|
+
|
|
|
440
|
+But for better results it is recommended to teach mtg about the website you
|
|
|
441
|
+will use as a domain front. In order to do that, you need to specify URLs
|
|
|
442
|
+from this website. Just go to it, open WebDeveloper console and pick up
|
|
|
443
|
+random URLs. For better results they have to be **from the same domain name
|
|
|
444
|
+you are going to use as a disguise** but serve light and heavy content: pages,
|
|
|
445
|
+images etc. Do not use many, 2-3 will probably work.
|
|
|
446
|
+
|
|
|
447
|
+mtg will crawl these pages periodically, accumulating statistics and
|
|
|
448
|
+using it as you go.
|
|
|
449
|
+
|
|
|
450
|
+```toml
|
|
|
451
|
+[defense.doppelganger]
|
|
|
452
|
+urls = [
|
|
|
453
|
+ "https://lalala.com/index.html",
|
|
|
454
|
+ "https://lalala.com/contacts.html",
|
|
|
455
|
+]
|
|
|
456
|
+```
|
|
|
457
|
+
|
|
|
458
|
+This is not very necessary. Keep in mind these rules:
|
|
|
459
|
+
|
|
|
460
|
+1. If you are not sure what is this all about, do nothing. Defaults are good.
|
|
|
461
|
+2. All URLs must be HTTPS
|
|
|
462
|
+3. All URLs should be from the same domain name (but this is not a rule)
|
|
|
463
|
+4. Do not use a lot of pages. Use _different_ pages. mtg will start using this
|
|
|
464
|
+ statistics when it will accumulate enough anyway.
|
|
|
465
|
+5. These URLs should be directly accessible from mtg without proxies whatsoever
|
|
|
466
|
+6. Do not create huge raids. mtg will repeatedly crawl in raids, making N repeats.
|
|
|
467
|
+ Do not use high N, you do not want to be noticeable.
|
|
|
468
|
+7. It makes no sense to have small delay between raids. Usually webservers
|
|
|
469
|
+ do not update their TLS settings each hour.
|
|
|
470
|
+8. If you have some specific knowledge if webserver is using
|
|
|
471
|
+ [TLS Dynamic Record Sizing](https://blog.cloudflare.com/optimizing-tls-over-tcp-to-reduce-latency/), you
|
|
|
472
|
+ can use a very specific setting. This are Cloudflare, Go standard webservers,
|
|
|
473
|
+ [caddy](https://caddyserver.com/) and [H2O](https://h2o.examp1e.net/). If so,
|
|
|
474
|
+ you can enable `drs` setting.
|
|
|
475
|
+9. **If you are not sure, touch nothing!**
|
|
|
476
|
+
|
|
401
|
477
|
## Metrics
|
|
402
|
478
|
|
|
403
|
479
|
Out of the box, mtg works with
|