0x hay 0s? Đọc hiểu định dạng PSK trong ipsec.secrets
Cùng một bí mật chia sẻ có thể được viết dưới dạng chuỗi nguyên văn trong ngoặc kép, dạng thập lục phân sau 0x, hoặc dạng Base64 sau 0s. Tiền tố sai khiến xác thực thất bại, không phải thương lượng.
Một máy khách xác thực được bằng khóa chia sẻ còn máy kia từ chối, dù các ký tự bạn dán trông giống hệt nhau ở cả hai bên. Nhiều khả năng chúng là cùng một ký tự; khác biệt nằm ở quy tắc giải mã mà tệp áp dụng cho chúng. Chuỗi trong ngoặc kép được hiểu nguyên văn, một token bắt đầu bằng 0x được đọc là thập lục phân, và một token bắt đầu bằng 0s được đọc là Base64. Chỉ một trong ba cách viết đó mang đúng ý bạn, nên cách sửa thường là chuyển đổi chứ không phải một mật khẩu tốt hơn.
Triệu chứng chỉ về mã hóa, không phải mật mã
Khi hai đầu giữ các byte khác nhau, thương lượng vẫn thành công và bước chứng minh thất bại sau đó. Nhật ký khi ấy báo lỗi toàn vẹn hoặc HMAC thay vì bất khớp thuật toán, vì một đề xuất đã được chọn và bước xác thực không khớp. Dòng đó không bao giờ nhắc đến hình dạng của bí mật.
Giai đoạn chính là đầu mối. Lỗi đến sau một đề xuất đã chọn nghĩa là hai bên đã thống nhất mọi thứ trừ vật liệu khóa, còn «không có đề xuất nào được chọn» thuộc về chính sách hoặc bộ mật mã. Một lần kiểm tra toàn vẹn thất bại trong khi mật khẩu trông đúng chính là bộ mặt hữu hình của bất khớp mã hóa.
Một bí mật, ba cách tệp có thể đọc nó
Với giá trị bốn byte key1, thập lục phân và Base64 là hai lần mã hóa lại của cùng các byte, và chỉ những ký tự đầu cho bộ phân tích biết nó đang giữ cách nào. Thông tin đăng nhập của swanctl theo cùng quy ước, nên một giá trị được chuyển giữa hai giao diện chỉ giữ nguyên ý nghĩa khi tiền tố của nó đi cùng.
10.20.0.5 %any : PSK "key1"
10.20.0.5 %any : PSK 0x6b657931
10.20.0.5 %any : PSK 0sa2V5MQ==
Hai chi tiết trong khối đó tốn nhiều thời gian nhất. Chữ số thập lục phân nhận cả hai kiểu viết, nên 0x6b657931 và 0x6B657931 là cùng một giá trị, nhưng số ký tự lẻ bị đọc sai một cách im lặng thay vì bị từ chối, khiến mọi byte sau chỗ cắt bị lệch. Phần đệm Base64 là một phần của giá trị, nên một chuỗi được dán mà thiếu các dấu = ở cuối sẽ được giải mã thành các byte khác thay vì thất bại ầm ĩ.
Một hồ sơ đã giải mã giá trị một lần là đã chuyển đổi nó, nên giải mã lần nữa tạo ra các byte khác và một lỗi xác thực đọc như mật khẩu sai. Dấu ngoặc kép là hướng an toàn cho mọi thứ mơ hồ, vì nội dung là nguyên văn kể cả khi nó bắt đầu bằng dấu hiệu mã hóa.
Văn bản Base64 đến từ đâu
Bản xuất hồ sơ và cổng nhà cung cấp thường trao khóa đã được mã hóa sẵn, thường trong một trường dữ liệu chưa bao giờ được thiết kế để gõ tay. Hoặc mở gói giá trị đó và lưu văn bản đã giải mã trong ngoặc kép, hoặc để nguyên mã hóa với dấu hiệu ở phía trước. Làm nửa này nửa kia chính là điều làm hỏng. Cả hai đường chỉ hoạt động nếu toàn bộ giá trị sống sót qua lần sao chép.
Cả hai chiều đều là một lệnh, và đáng giữ chúng trong phiếu như thao tác chính xác đã tạo ra giá trị được lưu. Chạy chúng theo thứ tự này:
printf '%s' 'a2V5MQ==' | base64 -d
printf '%s' 'key1' | base64
Dán văn bản đã mã hóa như thể nó là văn bản thường là sai lầm đắt giá. Tệp băm các ký tự đúng như đã viết, khóa dẫn xuất ra dài hơn khoảng một phần ba so với khóa mà đối tác tính, và mọi lần thử đều thất bại theo cùng một cách mà không có cảnh báo, vì bộ phân tích đã tuân theo quy tắc được đưa cho nó.
Xác nhận mỗi đối tác thực sự dùng những byte nào
Đọc trước góc nhìn của daemon về kết nối rồi sau đó là kết quả xác thực, thay vì đoán nguyên nhân từ chuỗi lỗi. So sánh độ dài đã lưu là một bước kiểm tra nhanh, vì văn bản đã mã hóa dài hơn các byte mà nó đại diện. Sau đó xác nhận dòng danh tính nào khớp, vì một bí mật đúng nằm dưới đối tác sai sẽ thất bại y hệt như bí mật sai. Thứ tự dòng quyết định điều đó: kết quả khớp đầu tiên thắng, nên một dòng %any rộng gần phía trên sẽ âm thầm thay thế dòng cụ thể mà bạn vừa sửa.
Tải lại thay vì khởi động lại khi tệp đã đúng. ipsec rereadsecrets làm mới bản sao của daemon IKE, và một cấu hình swanctl nạp thông tin đăng nhập bằng lệnh riêng của nó. Khởi động lại bỏ mọi liên kết đã thiết lập và phá hủy phép so sánh mà bạn đang cố thực hiện.
Không bước kiểm tra nào trong số này đòi hỏi phải lộ bí mật. Một độ dài, một bộ chọn danh tính và một vị trí dòng giải thích phần lớn các thất bại kiểu này trước khi ai đó cần đến một bản kết xuất thập lục phân.
Thay đổi tệp mà không che giấu kết quả
Giới hạn tệp cho tài khoản của daemon và giữ bí mật đang sống ngoài phiếu, trò chuyện và ảnh chụp màn hình, vì một khóa bị dán là rò rỉ chứ không phải chẩn đoán. Nó cũng sống lâu hơn sự cố đã sinh ra nó.
Kiểm thử từ một máy khách mà bạn kiểm soát cấu hình, xác nhận xác thực thành công, rồi xác nhận đường hầm mang lưu lượng. Một lần tải lại sửa được bắt tay trong khi định tuyến vẫn hỏng là vấn đề khác, và nó trở nên thấy được ngay khi bí mật ngừng di chuyển.