瀏覽代碼

Merge pull request #361 from 9seconds/docs

Add docs about doppelganger
tags/v2.2.0^2^2
Sergei Arkhipov 1 月之前
父節點
當前提交
58e6dfd603
沒有連結到貢獻者的電子郵件帳戶。
共有 2 個檔案被更改,包括 81 行新增0 行删除
  1. 76
    0
      README.md
  2. 5
    0
      mtglib/internal/doppel/stats.go

+ 76
- 0
README.md 查看文件

@@ -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

+ 5
- 0
mtglib/internal/doppel/stats.go 查看文件

@@ -61,6 +61,11 @@ const (
61 61
 //
62 62
 // In other word, a combination of Dynamic TLS Record Sizing hints us for
63 63
 // Weibull distribution.
64
+//
65
+// But we also have to keep in mind that DRS is not well spread yet. In most cases
66
+// users still rely on OpenSSL or webserver defaults. OpenSSL chunks with
67
+// biggest packet sizes, nginx relies on static setting that is 16k by default.
68
+// Thus, dynamic sizing has to be present but we cannot oblige users to use that.
64 69
 type Stats struct {
65 70
 	sizeLastRequested time.Time
66 71
 	sizeCounter       int

Loading…
取消
儲存