SSTP và SSL 3.0: nhãn dán so với phiên bản được thương lượng

Hai người có thể nhìn cùng một triển khai SSTP và đi đến kết luận trái ngược. Một người đọc tài liệu sản phẩm, thấy các chữ SSL và cho rằng đường hầm đang chạy một giao thức đã bị loại bỏ từ nhiều năm trước. Người kia chỉ vào một cái bắt tay hiện đại và kết luận câu hỏi đã khép lại. Cả hai đều tranh luận từ nhãn dán chứ không từ phiên bản được thương lượng, và chỉ một trong hai điều đó là bằng chứng. Phép so sánh đáng làm là giữa điều cái tên hứa hẹn và điều dịch vụ thực sự chọn.

Hai câu trả lời cho cùng một câu hỏi

Lập luận về nhãn dán dễ nêu: SSTP được mô tả là giao thức đường hầm socket an toàn, cái tên lịch sử nói SSL, vì vậy kết nối phải là SSL 3.0. Nó tồn tại được vì cái tên thực sự xuất phát từ dòng đó và vì phần lớn những người lặp lại nó chưa bao giờ nhìn vào một cái bắt tay. Nó cũng tồn tại được vì kết luận nghe có vẻ thận trọng, như thể giả định điều tồi tệ nhất là lựa chọn an toàn. Giả định điều tồi tệ nhất và đo phiên bản thực tế là hai hoạt động khác nhau, và chỉ một trong hai thay đổi được điều gì đó.

Lập luận về bằng chứng đặt một câu hỏi hẹp hơn. Máy khách này và máy chủ này đã đồng ý phiên bản giao thức nào, tại điểm cuối này, vào thời điểm này? Câu trả lời đến từ dịch vụ kết thúc TLS, không phải từ một trang tiếp thị hay từ trình duyệt đã đến một trang web có tên tương tự.

Hai lập luận khác nhau ở điều chúng có thể chứng minh. Nhãn dán không phân biệt được một triển khai cũ với một triển khai đã vá, và cái bắt tay không thể cho bạn biết một dịch vụ không liên quan trên cùng máy chủ đang làm gì. Hãy dùng cái thứ hai và ngừng dùng cái thứ nhất.

Đọc phiên bản mà dịch vụ thực sự chọn

Hãy bắt đầu bằng việc gọi tên các thành phần: phần triển khai máy khách, phần triển khai máy chủ, điểm cuối TLS và mọi thứ ở giữa kết thúc rồi thiết lập lại TLS. Một bộ cân bằng tải kết thúc TLS và nói HTTP thường với phần phía sau sẽ thay đổi việc bạn phải đọc chính sách của thiết bị nào.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null> | grep -E 'Protocol|Cipher'
Get-WinEvent -LogName System -ProviderName Schannel -MaxEvents 20

Hãy ghi lại điểm cuối và thời điểm cạnh kết quả, vì một thay đổi chính sách về sau khiến một quan sát không có ngày tháng trở nên vô dụng. Hãy lặp lại phép thử từ một máy khách trên cùng đường mạng với những người dùng bạn quan tâm, vì một thiết bị chặn có thể kết thúc TLS bằng cài đặt riêng của nó. Nếu hai vị trí không khớp, bạn đã tìm ra thành phần quan trọng. Nếu chúng khớp, bạn có bằng chứng chứ không phải khẩu hiệu.

Tách trường bản ghi khỏi phần thương lượng

Một số phiên bản trông cổ trong một trường không phải cùng một sự thật với một phiên SSL 3.0. RFC 7568 coi phiên bản của lớp bản ghi và giao thức được thương lượng là hai vấn đề riêng biệt, và chính từ sự phân biệt đó mới sinh ra những câu trả lời sai đầy tự tin. Hãy đọc giao thức được thương lượng, rồi đến bộ mã hóa, và chỉ sau đó mới kết luận về phiên.

Cùng văn bản đó rõ ràng về chính giao thức: không được dùng SSL 3.0, và việc thương lượng hay quay lại với nó bị cấm. Lý do là cấu trúc CBC hỏng mà cuộc tấn công POODLE đã lợi dụng, và đó là thuộc tính của giao thức chứ không phải cấu hình của một ứng dụng.

Vì vậy „khối lượng công việc này có lẽ khó khai thác” không phải là lý lẽ để giữ SSL 3.0 được bật. Yêu cầu là loại bỏ giao thức, không phải thắng một cuộc tranh luận về một cuộc trình diễn.

Loại bỏ SSL 3.0 bằng một chính sách bạn có thể bảo vệ

Trên Windows, các thiết lập giao thức của Schannel nằm dưới khóa Protocols và được đọc riêng cho vai trò máy khách và máy chủ, nên một thay đổi sửa một hướng có thể để hướng kia không bị đụng tới. Microsoft tài liệu hóa các thiết lập hiện tại và yêu cầu khởi động lại của chúng, còn một thư viện TLS của bên thứ ba trên cùng máy chủ thì bỏ qua hoàn toàn.

Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server'
Get-ChildItem 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols'

Hãy thay đổi chính sách qua đường quản trị được hỗ trợ, xác nhận dịch vụ sở hữu lấy lại cấu hình và giữ một đường lùi đã được phê duyệt. Dán một tập lệnh đăng ký rộng từ môi trường khác là cách một bản sửa của một dịch vụ trở thành sự cố cho mọi máy khách TLS trên máy. Phạm vi khởi động lại quan trọng ở đây: một thiết lập trông như đã áp dụng có thể vẫn còn trong bộ nhớ của dịch vụ chưa nạp lại nó.

Một đối tác vẫn đòi hỏi phiên bản lỗi thời cần được cập nhật hoặc có kế hoạch chuyển đổi. Một ngoại lệ không được ghi lại mà âm thầm khôi phục giao thức cũ không phải là chiến lược tương thích và sẽ không sống sót qua lần đánh giá tiếp theo.

Chấp nhận thay đổi với các kết nối mới

Hãy thử với các phiên mới sau khi đổi chính sách, vì một kết nối được thiết lập trước thay đổi không chứng minh gì về cấu hình đang có hiệu lực bây giờ. Xác nhận giao thức được phép thành công và giao thức bị cấm thất bại trong quy trình xác thực được ủy quyền, rồi để nguyên danh tính chứng chỉ và các kiểm tra tin cậy y như trước.

Hãy nhớ điều cái bắt tay không bao gồm. SSTP mang xác thực PPP sau lớp TLS, nên một phiên bản giao thức hiện đại không nói gì về việc người dùng nào được cấp quyền hay phiên có thể chạm tới tài nguyên nào. Đó là những kiểm soát riêng với bằng chứng riêng.

Hãy ghi kết quả thành dịch vụ, phần phía sau, chính sách được phép và phiên bản quan sát được. Một bản ghi như vậy trả lời chính xác câu hỏi bảo mật, điều mà cả lập luận về nhãn dán lẫn lập luận về sự bất tiện đều không bao giờ làm được.