Kết nối SSH qua HTTPS

Truyền SSH qua HTTPS

• Để truyền SSH qua HTTPS, cần điều chỉnh cả phía client lẫn server.
• Trong ví dụ cấu hình client, thiết lập ProxyCommand và ServerAliveInterval trong tệp ~/.ssh/config.
• Script ~/.ssh/https-tunnel.bash được sử dụng tạo kết nối TLS bằng socat đồng thời gửi phương thức CONNECT trong phần header.

Ví dụ cấu hình server

• Trong cấu hình máy chủ HTTPS Apache2, nạp proxy_connect_module và dùng chỉ thị AllowCONNECT để cho phép sử dụng phương thức HTTP CONNECT tới các đích cụ thể.
• Ở phía server, cấu hình để trên https-server chỉ cho phép dùng phương thức CONNECT dành cho duy nhất host đích ssh-server.

Bối cảnh

• Trong lúc ở lại bệnh viện, tác giả muốn làm việc từ xa thông qua Wi-Fi của bệnh viện, nơi hầu hết các kiểu kết nối đều bị chặn.
• Mạng của bệnh viện chỉ cho phép kết nối HTTP và HTTPS, còn SSH thì bị chặn hoàn toàn.
• Tác giả tìm cách truyền SSH qua HTTP hoặc HTTPS.

Các cách khả thi

• Dự án sslh, cho phép đồng lưu trữ giao thức SSH và HTTPS trên một cổng duy nhất rồi phân phối một cách trong suốt.
• sslh không bọc một giao thức vào trong giao thức khác mà dùng nhiều heuristic khác nhau để chuyển hướng tới backend thực tế.
• Cách dùng chỉ thị ProxyCommand của openssh để bọc hoàn toàn giao thức SSH vào trong một giao thức khác.

SSH over HTTP

• Để thử nghiệm SSH over HTTP đơn giản, cấu hình Apache2 để cho phép phương thức CONNECT với đích duy nhất ssh-server:22.
• Phía client có thể điều chỉnh dễ dàng bằng socat.
• Dùng ServerAliveInterval để kết nối HTTP không bị ngắt ngay cả khi ở trạng thái nhàn rỗi.

SSH over HTTPS

• socat không hỗ trợ HTTPS proxy nhưng có hỗ trợ đóng gói TLS.
• Có thể tự triển khai khá dễ phương pháp dựa trên CONNECT.
• Sử dụng script ~/.ssh/https-tunnel.bash để triển khai đường hầm SSH over HTTPS.

Kết luận

• Sự hiện diện phổ biến của HTTPS cho phép truyền dữ liệu qua các thiết bị trung gian bị giới hạn rất chặt chẽ.
• Phương thức CONNECT là một mẹo hữu ích để bọc luồng payload TCP vào luồng host TLS.
• ServerAliveInterval được dùng để duy trì kết nối trên các lớp truyền tải bên dưới vốn không thân thiện với kết nối nhàn rỗi.

Ý kiến của GN⁺

• Điểm quan trọng nhất của bài viết này là đã đưa ra một giải pháp sáng tạo giúp có thể kết nối SSH ngay cả trong môi trường mạng bị hạn chế.
• Cách kết hợp SSH và HTTPS có thể đặc biệt thú vị với những người có kiến thức chuyên môn về bảo mật mạng.
• Cách vượt qua các giới hạn mạng bằng thiết lập ProxyCommand và ServerAliveInterval cung cấp thông tin hữu ích cho quản trị viên mạng hoặc chuyên gia bảo mật.

[GN⁺]

Ý kiến Hacker News

• Nhà cung cấp Internet XS4ALL của Hà Lan trước đây từng cung cấp truy cập SSH qua cổng 80. Tính năng này rất hữu ích khi các cổng khác bị chặn, chẳng hạn như trên Wi‑Fi khách sạn.
• Sự hiện diện phổ biến của HTTPS cho phép truyền dữ liệu qua các thiết bị trung gian bị giới hạn nghiêm ngặt. Đây là lý do chính khiến các giao thức VPN độc quyền được gọi là SSL VPN triển khai chế độ khởi tạo đường hầm qua HTTPS.
• Cũng có thể đặt SSH trên cổng 80 hoặc 443 rồi dùng ProxyJump qua một host khác, hoặc lấy kết nối Internet ít bị hạn chế hơn thông qua SOCKS. Cũng có thể chuyển tiếp DNS over TLS qua kết nối SSH.
• Một công ty tên Adaptive đang xây dựng hạ tầng bảo mật dữ liệu cung cấp SSH và nhiều giao thức khác qua HTTP3. Nhờ đó, người dùng có thể kết nối tới cơ sở dữ liệu, máy chủ và các tài nguyên khác thông qua các cổng bên ngoài.
• Trên thực tế, phần lớn tường lửa có thể bị vượt qua chỉ bằng cách để openssh lắng nghe trên cổng 443.
• Việc xem phương thức CONNECT như một reverse proxy thay vì một forward proxy là một điểm thú vị. Tuy nhiên, chỉ CONNECT thôi là chưa đủ, nên người ta dùng SSH qua WebSocket để vượt qua proxy doanh nghiệp.
• Tần suất xuất hiện của các bài viết về những giải pháp “mới” gây khó chịu. Những ý tưởng này không hề mới và nhiều người đã biết từ lâu.
• Sẽ thật tuyệt nếu một hệ thống quản lý danh tính tương tự SSH được tích hợp sẵn trong trình duyệt. Khi lần đầu đọc về đề xuất xác thực HTTP bằng khóa công khai tên là hobo, tôi đã rất hào hứng, nhưng rồi phát hiện ra không có triển khai phía máy chủ và cũng không tồn tại triển khai phía client (trình duyệt).
• Khoảng 20 năm trước, tôi đã dùng một công cụ tên là corkscrew để đi xuyên qua tường lửa doanh nghiệp. Triển khai độc lập và phần giải thích về công cụ này rất ấn tượng.
• Tunneling qua HTTP2 là một lựa chọn rất tốt. Có gRPC, một giao thức RPC được xây dựng trên HTTP2. HTTP2 rất xuất sắc trong việc truyền và nhận đồng thời nhiều cấu trúc dữ liệu qua kết nối TCP. Tuy nhiên, có thể không cần dùng HTTP3, vì bản thân QUIC đã cung cấp khả năng multiplexing.