Lưu trữ trang .onion trên VPS mà không làm lộ máy chủ

Hãy bắt đầu từ điều thực sự khác biệt, vì nó không chỉ đơn thuần là một hostname trông kỳ lạ. Một trang web thông thường phụ thuộc vào một chuỗi các bên bên ngoài, còn một dịch vụ onion đơn giản là không có chuỗi đó.

• Không nhà đăng ký và không registry. Một địa chỉ onion v3 là bản mã hóa base32 của một khóa công khai ed25519, cộng thêm một checksum và một byte phiên bản — năm mươi sáu ký tự, được tạo ra ngay trên máy của bạn trong một phần rất nhỏ của giây. Không ai bán nó cho bạn, nên không ai lấy lại được nó, và cũng chẳng có ngày gia hạn nào. Đó là điều hoàn toàn ngược lại với mô hình rủi ro trong hướng dẫn đăng ký tên miền riêng tư của chúng tôi.
• Không DNS. Chẳng có gì phân giải một tên .onion cả. Client hỏi mạng Tor để lấy một descriptor đã ký được xuất bản dưới khóa đó, nên không có resolver nào để đầu độc, không có zone nào để rò rỉ và không có nameserver nào để đánh sập.
• Không đơn vị cấp chứng chỉ. Địa chỉ chính là khóa công khai, nên client xác minh dịch vụ dựa trên đúng cái tên nó đã gõ. Đây là ý nghĩa của “tự xác thực”: không có bên thứ ba nào đứng ra bảo lãnh cho danh tính, vì danh tính và địa chỉ chính là cùng một thứ.
• Không cổng inbound. Dịch vụ mở các circuit outbound tới một số ít điểm giới thiệu (introduction point) rồi chờ ở đó. Firewall của bạn có thể chặn mọi gói tin inbound mà trang vẫn hoạt động bình thường. Không có gì đang lắng nghe trên một địa chỉ công khai, nên chẳng có gì để quét, chẳng có gì để fingerprint và chẳng có gì để làm ngập trực tiếp.

Một lưu ý mang tính lịch sử vẫn còn gây nhầm lẫn: các địa chỉ mười sáu ký tự kiểu cũ đã không còn nữa. Việc hỗ trợ dịch vụ onion phiên bản 2 đã bị gỡ khỏi Tor vào tháng 10 năm 2021, các địa chỉ đó không còn hoạt động ở bất cứ đâu, và bất cứ tài liệu nào bạn tìm thấy mô tả chúng đều đã lỗi thời. Mọi thứ dưới đây đều là v3, loại duy nhất còn tồn tại.

Và hãy hiểu rõ những gì tất cả những điều trên không loại bỏ được. Vẫn còn đó một cỗ máy vật lý trong một trung tâm dữ liệu, một nhà cung cấp biết nó tồn tại, một hóa đơn ai đó đã trả, và một ứng dụng có thể bị xâm nhập. Dịch vụ onion đưa lớp địa chỉ ra khỏi tầm với. Chúng không đưa máy chủ ra khỏi tầm với.

Người ta đến với Tor để làm một trong bốn việc khá khác nhau, và hồ sơ rủi ro của chúng không hề giống nhau chút nào. Đáng để biết rõ bạn đang đăng ký làm việc nào.

• Một relay trung gian chuyển tiếp lưu lượng đã mã hóa giữa các relay khác. Nó mang dữ liệu của người khác, nhưng không bao giờ chạm vào internet mở thay mặt họ, nên không thu hút khiếu nại nào.
• Một bridge là một điểm vào chưa được liệt kê dành cho những người bị chặn truy cập Tor. Cùng hồ sơ lưu lượng như một relay trung gian, chỉ khác là địa chỉ được giữ ngoài danh mục công khai.
• Một exit relay là nơi lưu lượng của người khác rời khỏi Tor và đến với internet thông thường, dưới địa chỉ IP của bạn. Đây là loại tạo ra thư lạm dụng và thư từ pháp lý, và nó cần được xử lý một cách có chủ đích — hướng dẫn Tor relay của chúng tôi trình bày đầy đủ về việc đó.
• Một dịch vụ onion thì xuất bản. Nó chỉ mang lưu lượng của chính nó, không bao giờ liên hệ với clearweb thay mặt bất kỳ ai, và do đó không tạo ra báo cáo lạm dụng nào nhắm vào IP của bạn cả. Không có exit, nên chẳng có gì để thoát ra.

Điểm cuối cùng đó đáng để dừng lại suy ngẫm, vì nó thường xuyên bị hiểu sai. Vận hành một dịch vụ onion, xét về mặt vận hành, là điều yên tĩnh nhất bạn có thể làm trên mạng Tor. Máy chủ của bạn tạo ra các kết nối outbound trông giống hệt lưu lượng client Tor thông thường; nó không bao giờ xuất hiện như nguồn gốc của một kết nối tới máy chủ của người khác; và điều mà hầu hết mọi người lo lắng — hành vi của người khác đổ lên đầu IP của bạn — là điều không thể xảy ra về mặt cấu trúc.

Bạn cũng không cần chạy một relay để chạy một dịch vụ onion, và tách riêng hai thứ đó ra thì tốt hơn. Một relay cần băng thông, một ORPort công khai và một ContactInfo đã công bố. Một dịch vụ không cần bất kỳ thứ nào trong số đó. Nếu bạn muốn làm cả hai, hãy làm chúng trên hai máy chủ khác nhau.

Đây là phần mà tài liệu chính thức nói khá sơ sài, và cũng là phần thực sự quyết định việc làm này có đáng công hay không. Tor, khi được cấu hình như bên dưới, rất khó có khả năng là thứ làm lộ máy chủ của bạn. Phần mềm đứng sau nó mới là thủ phạm, vì phần mềm đó được viết ra với giả định rằng một web server muốn được tìm thấy.

Sau đây là các kênh rò rỉ, xếp theo thứ tự gần đúng về tần suất chúng khiến người ta bị lộ:

• Cùng một nội dung trên IP công khai. Nếu web server của bạn cũng lắng nghe trên 0.0.0.0, bất kỳ ai quét internet đều thấy y hệt một trang trên cả một địa chỉ IP lẫn một địa chỉ onion. Các trình quét toàn bộ internet lập chỉ mục liên tục mọi cổng đang mở, và kết quả của chúng có thể tìm kiếm được theo body hash lẫn favicon hash. Chỉ một truy vấn là liên kết được cả hai. Đây là cách phổ biến nhất khiến một dịch vụ onion bị lộ mặt, và nó chỉ là một lỗi cấu hình vỏn vẹn một dòng.
• Banner máy chủ và các trang mặc định. Một bản cài nginx hay apache2 nguyên bản trả lời các hostname không xác định bằng một trang mặc định, in phiên bản của nó trong header Server, và thường để lộ hostname thật của máy trong kết quả báo lỗi. Mỗi thứ trong số đó đều là một điểm neo để đối chiếu (correlation handle).
• URL tuyệt đối. Redirect, thẻ canonical, sitemap, RSS feed, thẻ Open Graph và email đặt lại mật khẩu đều rất "thích" phát ra một URL clearweb đầy đủ. Chỉ cần một trong số đó xuất hiện bên trong phiên bản onion của một trang là đủ.
• Các request outbound mà ứng dụng thực hiện. Analytics, web font, tài nguyên CDN, dịch vụ avatar, map tile, webhook và kiểm tra cập nhật đều xuất phát từ địa chỉ IP thật của máy chủ, và một số trong đó còn báo cho bên thứ ba biết trang nào đang được hiển thị vào đúng thời điểm đó. Một trang tự lưu trữ (self-hosted) nhưng tải font từ tên miền của người khác sẽ có một dấu vết kiểm toán mà nó không hề chủ ý tạo ra.
• Mail. Bất cứ thứ gì máy gửi đi đều đóng dấu IP thật của nó vào các header Received. Nếu dịch vụ cần gửi mail, đó là một vấn đề thiết kế cần được giải quyết một cách có chủ đích — hãy bắt đầu từ hướng dẫn mail server của chúng tôi, và mặc định giả định rằng nó không nên gửi bất cứ thứ gì cả.
• Khóa và fingerprint bị dùng lại. Cùng một SSH host key trả lời trên cả IP công khai lẫn một địa chỉ onion sẽ liên kết chúng vĩnh viễn. Cùng một chứng chỉ TLS, cùng một favicon, cùng một mã định danh analytics, hay cùng một trang lỗi đặc trưng xuất hiện ở hai dự án cũng gây ra điều tương tự.
• Certificate Transparency. Nếu cùng một máy từng phục vụ một tên miền clearweb qua HTTPS, chứng chỉ của tên miền đó sẽ được ghi vào các nhật ký append-only công khai mãi mãi. Điều đó chỉ đích danh cỗ máy, không phải địa chỉ onion — nhưng nó vẫn chỉ đích danh cỗ máy.

Hình dạng chung của tất cả những điều trên đều giống nhau: Tor đã giấu địa chỉ, còn thứ gì đó khác trên máy chủ lại đem nó công bố ra. Bước tám bên dưới là một danh sách kiểm tra để tìm ra chúng trước khi ai đó khác làm điều đó.

Trước khi cài đặt bất cứ thứ gì, hãy trả lời một câu hỏi, vì mọi thứ sau đó đều phụ thuộc vào nó: vị trí vật lý của máy chủ này có phải là một bí mật bạn đang cố gắng giữ kín hay không?

Có ba câu trả lời trung thực, và chúng dẫn tới những cách xây dựng thực sự khác nhau.

• Có, vị trí chính là vấn đề cốt lõi. Khi đó máy này chỉ làm đúng một việc. Không trang clearweb, không bản ghi DNS công khai nào trỏ tới IP của nó, không mail, không dịch vụ nào khác lắng nghe ở bất cứ đâu. Bạn thanh toán cho nó theo cách không gắn tên bạn vào — hướng dẫn Monero của chúng tôi trình bày cơ chế cụ thể, và tài khoản no-KYC nghĩa là chẳng có gì phải giao nộp ngoài một địa chỉ để nhận hàng. Bạn giữ nguyên cấu hình đầy đủ ba chặng. Mọi lối tắt bên dưới đánh đổi tính ẩn danh để lấy tốc độ đều bị đóng lại với bạn, và điều đó ổn thôi, vì bạn không tối ưu cho tốc độ.
• Không, máy chủ vốn đã công khai. Bạn vận hành một trang web bình thường và muốn có thêm một địa chỉ onion — để phục vụ độc giả sống sau kiểm duyệt, cho những người không muốn phải phân giải tên miền của bạn, hoặc đơn giản chỉ vì bạn muốn cung cấp nó. Không ai đang giấu giếm điều gì cả, nên bạn có thể dùng một single onion service, rút circuit từ sáu chặng xuống còn ba, và quảng bá địa chỉ đó từ trang clearweb bằng một header Onion-Location. Đây là một tính năng về khả năng tiếp cận, và đó là một lý do hoàn toàn chính đáng để có mặt ở đây.
• Ở đâu đó lưng chừng giữa hai điều trên. Đây là chỗ mà hầu hết mọi người thực sự đang đứng, và đó là vị trí nguy hiểm nhất, vì “ẩn một phần nào đó” không phải là một thuộc tính mà một máy chủ có thể có. Hãy chọn một phe. Nếu vị trí thực sự quan trọng, hãy xây dựng nó như thể nó quan trọng. Nếu không, đừng tiếp tục trả giá về độ trễ cho một thuộc tính ẩn danh mà bạn không hề duy trì.

Hãy ghi lại câu trả lời trước khi tiếp tục. Gần như mọi sai lầm trong chủ đề của hướng dẫn này đều bắt nguồn từ việc xây dựng theo trường hợp đầu tiên rồi vận hành như thể nó là trường hợp thứ hai.

Nếu vị trí của máy chủ không phải là một bí mật, việc chạy song song cả hai là điều đơn giản và thực sự hữu ích — đó là cách các hãng tin lớn, Debian và một số công cụ tìm kiếm cung cấp trang của họ. Có hai cơ chế và một sự đánh đổi cần hiểu rõ.

Quảng bá nó bằng Onion-Location. Chỉ một header trên trang clearweb khiến Tor Browser hiện một nút “.onion available” trên thanh địa chỉ, và đề nghị chuyển sang đó. Header này chỉ được tôn trọng trên các trang phục vụ qua HTTPS, và giá trị của nó phải là một URL onion hợp lệ:

add_header Onion-Location "http://<your-address>.onion$request_uri" always;

Có một dạng tương đương bằng HTML cho các host không thể đặt header, và nó cũng có cùng yêu cầu về HTTPS:

<meta http-equiv="onion-location" content="http://<your-address>.onion">

Cũng hãy đặt địa chỉ đó ở đâu đó mà con người có thể đọc được, trong footer hoặc trên một trang giới thiệu. Header chỉ tiếp cận được những người đã dùng sẵn Tor Browser; footer tiếp cận mọi người còn lại.

Cân nhắc một single onion service. Một kết nối onion bình thường có sáu chặng — ba từ phía client, ba từ phía dịch vụ — và ba chặng của dịch vụ chỉ tồn tại để giấu vị trí của nó. Nếu điều đó không phải là một bí mật, bạn có thể bỏ chúng đi. Mức cải thiện độ trễ là rất lớn và nhận thấy được ngay lập tức. Cấu hình này cố tình được viết thẳng thừng:

# /etc/tor/torrc — these are INSTANCE-WIDE, not per service
HiddenServiceNonAnonymousMode 1
HiddenServiceSingleHopMode 1
SOCKSPort 0

Cả hai tùy chọn đều bắt buộc phải đi cùng nhau, cổng SOCKS phải bị vô hiệu hóa, và chúng áp dụng cho mọi dịch vụ onion trên cùng một instance Tor đó — không có tùy chọn tắt riêng cho từng dịch vụ. Tor sẽ từ chối khởi động nếu bạn đặt một tùy chọn mà thiếu các tùy chọn còn lại, đó là phần mềm đang giúp bạn một việc tốt. Nếu một instance duy nhất lưu trữ một dịch vụ có vị trí công khai và một dịch vụ khác có vị trí không công khai, hãy chạy hai instance, hoặc tốt hơn, hai máy chủ riêng biệt.

Và chấp nhận sự đánh đổi. Việc công bố cả hai địa chỉ tuyên bố rằng cùng một người vận hành cả hai, và việc phục vụ cùng một nội dung từ cả hai khiến chúng trở nên dễ dàng liên kết với nhau dù thế nào đi nữa. Đó là cái giá phải trả, và với một trang công khai thì nó chẳng tốn kém gì cả. Dù vậy vẫn hãy giữ vệ sinh: không có URL clearweb tuyệt đối nào bên trong phiên bản onion, cookie được giới hạn phạm vi theo từng host để một phiên không di chuyển giữa chúng, và một chính sách bảo mật nội dung (content security policy) không kéo tài nguyên từ nơi khác vào.

Theo mặc định, bất kỳ ai biết địa chỉ của bạn đều có thể truy cập được dịch vụ. Ủy quyền client (client authorization) thay đổi điều đó ở tầng mạng thay vì tầng ứng dụng, và sự khác biệt này quan trọng hơn nhiều so với vẻ ngoài của nó.

Khi bật ủy quyền, descriptor mà dịch vụ của bạn công bố sẽ được mã hóa cho một tập hợp khóa client. Một khách truy cập không có một trong các khóa đó không thể giải mã descriptor, không thể biết được các điểm giới thiệu (introduction point), và do đó hoàn toàn không thể kết nối — họ không đi tới được một trang đăng nhập, họ không nhận được một lời từ chối, họ chẳng nhận được gì cả. Dịch vụ không phải là không được liệt kê; nó vô hình hoàn toàn.

Hãy tạo một cặp khóa x25519 cho mỗi client. Mọi công cụ ở đây đều đã có sẵn trên một máy Debian:

openssl genpkey -algorithm x25519 -out alice.prv.pem

# private key — goes to the client, never to the server
grep -v 'PRIVATE KEY' alice.prv.pem | base64 -d | tail -c 32 | base32 | tr -d '='

# public key — goes on the server
openssl pkey -in alice.prv.pem -pubout | grep -v 'PUBLIC KEY' \
  | base64 -d | tail -c 32 | base32 | tr -d '='

Trên máy chủ, thả khóa công khai vào một thư mục authorized_clients bên trong thư mục dịch vụ. Tên tệp có thể tùy ý miễn là kết thúc bằng .auth, điều này khiến việc thu hồi chỉ đơn giản là xóa một tệp:

mkdir -p /var/lib/tor/onion-site/authorized_clients
echo "descriptor:x25519:<ALICE-PUBLIC-KEY>" \
  > /var/lib/tor/onion-site/authorized_clients/alice.auth
chown -R debian-tor:debian-tor /var/lib/tor/onion-site
systemctl reload tor@default

Trên máy client, khóa riêng tư được đặt trong thư mục do ClientOnionAuthDir chỉ định, trong một tệp kết thúc bằng .auth_private, với địa chỉ được lặp lại bên trong đó. Tor Browser có thư mục riêng cho những tệp này bên trong thư mục dữ liệu của nó, và sẽ hỏi xin một khóa nếu nó gặp một dịch vụ cần đến khóa đó:

# /var/lib/tor/onion-auth/mysite.auth_private
<address-without-the-.onion>:descriptor:x25519:<ALICE-PRIVATE-KEY>

Đây là công cụ phù hợp cho một trang staging, một bảng quản trị, một nơi chia sẻ tệp riêng tư, hay một Nextcloud tự lưu trữ mà chỉ mình bạn sử dụng — bất cứ thứ gì mà câu trả lời trung thực cho câu hỏi “ai nên có thể thấy được thứ này tồn tại?” là “không ai ngoài chúng ta”. Cái giá phải trả là có thật và mang tính hành chính: bạn phải đưa khóa cho người khác qua một kênh mà bạn tin tưởng, và bạn phải nhớ gỡ bỏ chúng sau đó.

Dịch vụ onion gặp sự cố theo những cách rất riêng của chúng, và không cái nào trong số đó trông giống một sự cố ngừng hoạt động thông thường. Có bốn điều đáng để thiết lập trước khi bạn cần đến chúng.

Tấn công từ chối dịch vụ (denial of service) là vấn đề vận hành thực sự. Vì không có địa chỉ IP nào để lọc, các biện pháp phòng thủ thông thường không áp dụng được, và một đợt lũ yêu cầu giới thiệu (introduction request) có chủ đích lại rất rẻ để thực hiện. Tor có hai giải pháp, cả hai đều được đặt theo từng dịch vụ trong torrc: HiddenServiceEnableIntroDoSDefense 1 giới hạn tốc độ các yêu cầu tại các điểm giới thiệu, còn HiddenServicePoWDefensesEnabled 1 buộc client phải giải một câu đố proof-of-work nhỏ, câu đố này khó dần lên khi tải tăng, để khách truy cập hợp lệ chỉ phải chờ một chút trong khi một đợt lũ tấn công trở nên đắt đỏ. Hãy bật cả hai ngay từ đầu; chi phí phải trả khi không có ai tấn công là không đáng kể.

Giữ đồng hồ chính xác. Các descriptor được công bố và tra cứu dựa trên các khoảng thời gian suy ra từ một giá trị mạng dùng chung. Một máy chủ có đồng hồ lệch nghiêm trọng sẽ công bố sai chỗ và trở nên không thể truy cập được trong khi vẫn trông hoàn toàn khỏe mạnh trong nhật ký của chính nó. Hãy đảm bảo một client NTP đang chạy, giữ máy ở múi giờ UTC, và kiểm tra điều này khi một dịch vụ bỗng dưng ngừng phân giải một cách bí ẩn.

Giám sát bắt buộc phải đi qua Tor. Không một dịch vụ uptime thương mại nào có thể dò được một địa chỉ .onion, nghĩa là giải pháp thông thường không dùng được cho bạn. Hãy tự chạy việc kiểm tra đó từ một máy thứ hai không phải là máy đang lưu trữ dịch vụ — một cron job chạy torsocks curl -s --max-time 60 nhắm vào một URL đã biết, so sánh kết quả với một chuỗi đã biết, là đủ và không tốn gì cả.

Hãy tính đến nhiều hơn một instance nếu uptime quan trọng. OnionBalance cho phép nhiều máy chủ backend chia sẻ chung một địa chỉ onion: một instance front-end giữ khóa sở hữu địa chỉ đó và công bố một descriptor trỏ tới các điểm giới thiệu của các backend, nhờ đó bạn có được phân tải và chuyển đổi dự phòng (failover) mà địa chỉ không bao giờ thay đổi. Đây là nhiều bộ phận chuyển động hơn mức hầu hết các trang cần đến, nhưng đó là giải pháp được hỗ trợ chính thức, và đáng để biết rằng nó tồn tại trước khi bạn tự dồn mình vào thế chỉ có một máy duy nhất.

Một thói quen vận hành cuối cùng: khởi động lại Tor khiến dịch vụ offline trong vài giây trong khi nó công bố lại, còn một lần cài lại xóa sạch /var/lib/tor sẽ khiến nó offline vĩnh viễn. Hãy đối xử với thư mục đó như cách bạn đối xử với một khóa bí mật, vì nó chính là một khóa bí mật.

Một địa chỉ onion loại bỏ nhà đăng ký, resolver, đơn vị cấp chứng chỉ và cổng đang mở. Nó không loại bỏ bất cứ điều gì khác, và việc rạch ròi về phần còn lại chính là điều phân biệt giữa một công cụ hữu ích và một cảm giác an toàn giả tạo.

Nó không sửa được ứng dụng. Một web app có lỗ hổng đứng sau một dịch vụ onion vẫn là một web app có lỗ hổng; việc đầu tiên nhiều kẻ tấn công làm sau khi có được khả năng thực thi mã là gửi một request outbound để lộ địa chỉ thật của máy chủ. Hãy cho máy trải qua lượt mười phút trong hướng dẫn tăng cường bảo mật Debian của chúng tôi, giữ nó luôn được vá lỗi, và coi nó như đang bị phơi ra ngoài dù chẳng có gì đang lắng nghe.

Nó không giấu được máy chủ khỏi những người vận hành nó. Chúng tôi biết một máy chủ tồn tại, biết nó được triển khai khi nào, và biết địa chỉ IP của nó là gì, vì chính chúng tôi là bên đã cấp phát nó. Điều đó đúng với mọi nhà cung cấp, ở bất cứ đâu, và bất kỳ ai nói với bạn điều ngược lại đều đang cố bán cho bạn thứ gì đó. Điều chúng tôi có thể nói chính xác là chúng tôi làm gì với thông tin đó, được trình bày trong bài viết trung thực về những gì một VPS trả bằng crypto thực sự che giấu được của chúng tôi.

Nó không tự mình đánh bại được một đối thủ kiên nhẫn và có đủ nguồn lực. Khối lượng lưu lượng và thời điểm gửi vẫn hiện ra ở các rìa của mạng lưới, và một dịch vụ im bặt mỗi khi một người cụ thể nào đó đang ngủ thì đang tự nói lên điều gì đó. Nó cũng chẳng giúp được gì nếu chính nội dung nhận diện ra bạn: cùng một văn phong, cùng một khóa PGP, cùng một avatar hay cùng một biệt danh diễn đàn từng dùng cho một danh tính công khai sẽ khép kín vòng lặp đó, bất kể lớp truyền tải có tốt đến đâu.

Về phía chúng tôi, để bạn có cơ sở đối chiếu: dịch vụ onion được chào đón ở mọi gói và không cần bất cứ điều gì đặc biệt từ chúng tôi, vì chúng không mở cổng nào và không tạo ra lưu lượng lạm dụng nào cả. Chúng tôi vận hành các tài khoản no-KYC chỉ cần một địa chỉ để giao thông tin đăng nhập tới. Chúng tôi coi các thư từ bản quyền thông thường là một vấn đề vận hành chứ không phải một lượt gỡ xuống tự động, chúng tôi tuân theo các lệnh tòa án hợp lệ tại khu vực pháp lý nơi máy chủ đặt, và giới hạn cứng là tuyệt đối, áp dụng ở đây giống hệt như ở mọi nơi khác: không CSAM, không nội dung khủng bố, không ngoại lệ. Hãy đọc chính sách sử dụng chấp nhận được và cách chúng tôi xử lý báo cáo lạm dụng trước khi bạn xây dựng thứ gì đó mà bạn sẽ không vui nếu phải di dời. Trang VPS thân thiện Tor của chúng tôi có hướng dẫn chọn gói.