2011-07-12 21 views
5

Tôi muốn mã hóa dữ liệu truyền qua lại giữa máy chủ và ứng dụng khách trong ứng dụng Web của tôi. Tôi sẽ sử dụng SSL nhưng điều đó đòi hỏi một chứng chỉ cùng với một địa chỉ IP chuyên dụng. Tôi không có vấn đề gì khi nhận được chứng chỉ nhưng IP chuyên dụng yêu cầu tôi nâng cấp lên kế hoạch lưu trữ doanh nghiệp với mức phí $ 20 một tháng trên máy chủ web của tôi. Tôi không có kế hoạch làm điều đó khi tôi gắn bó với kế hoạch lưu trữ chia sẻ 20 đô la/năm của mình.Thay thế cho SSL - Mã hóa "thủ công"?

Vì vậy, tôi muốn triển khai thay thế cho SSL. Tuy nhiên, nó thực hiện nhiều hơn SSL. Cùng với việc mã hóa dữ liệu được gửi qua lại, nó cũng mã hóa các hàng trong cơ sở dữ liệu. Tôi đã nghĩ đến việc làm một cái gì đó như thế này:

Javascript Code:

var transfer_key = 'whatever'; 
function encrypt(data, key) {...} 
function decrypt(data, key) {...} 

function send_data_to_server(url, data) 
{ 
    $.post(url, {'data' : encrypt(data, transfer_key) }, function(response) { 
     var decrypted_response = JSON.parse(decrypt(response)); 
    }); 
} 

PHP Code:

$data = $_POST['data']; 
$transfer_key = 'whatever'; 
$storage_key = 'whatever2'; 

function encrypt($data, $key) {...} 
function decrypt($data, $key) {...} 

databaseQuery('INSERT INTO table VALUES (?)', encrypt($data, $storage_key)); 

$decrypted_data = decrypt($data, $transfer_key); 
$response = processData($decrypted_data); 

echo encrypt($transfer_key, $response); 

Như bạn có thể thấy, các dữ liệu khách hàng gửi đến máy chủ được mã hóa và ngược lại. Và dữ liệu trong cơ sở dữ liệu cũng được mã hóa. Bây giờ tất nhiên, tôi sẽ không bao giờ thực hiện các phím như thế. Tôi có thể sẽ có một khóa thứ hai hoặc thứ ba được tạo ngẫu nhiên cho mỗi người dùng. Vì vậy, transfer_key có thể bằng với một hằng số_key được nối với một khóa ngẫu nhiên, và tương tự như vậy cho storage_key.

Đây có phải là giải pháp thay thế tốt cho SSL không? Làm thế nào tôi có thể thực hiện loại mã hóa này theo cách mà khó đánh bại hơn? Có bất kỳ điểm yếu cụ thể nào đối với phương pháp này không?

Tôi có thể sẽ tìm một thư viện JS để quản lý mã hóa và sử dụng phần mở rộng mcrypt của PHP cho phía máy chủ. Tôi đã nghĩ đến Blowfish, có lẽ AES256, nhưng tôi không chắc cái nào mang lại cho tôi tỷ lệ mã hóa tốt nhất để tiêu thụ bộ nhớ.

Lời khuyên?

+2

Tôi không biết rằng SSL yêu cầu IP chuyên dụng.Ngoài ra, tôi biết đây là mã giả, nhưng vào lúc này, 'DBData = mã hóa (mã hóa (clientData, transfer_key), storage_key) '- nếu như bạn chỉ ra, transfer_key là tạm thời theo một cách nào đó, có nghĩa là bạn không bao giờ có thể giải mã dữ liệu cơ sở dữ liệu. –

+4

Vì vậy, tất cả tôi (như một kẻ tấn công) phải làm là đánh hơi lưu lượng html đơn giản mà bạn gửi cho khách hàng có chứa mã javascript với các khóa mã hóa/giải mã. tốt ... Nghiêm túc, gắn bó với SSL/TLS – NotMe

+1

@Damien_The_Unbeliever: bản thân SSL thì không; nhưng nhà cung cấp của anh ta có thể đóng gói nó như là một phần của một kế hoạch đắt tiền hơn. – NotMe

Trả lời

41

Uh, oh. Chúc may mắn với điều đó. Bạn đã xem qua số TLS specification chưa? Bạn có nghĩ rằng bạn có thể đưa ra một cái gì đó đầy đủ mà sẽ được hàng triệu người kiểm tra?

Không, thực sự, TLS đã được thử nghiệm và cải thiện qua nhiều năm bởi rất nhiều người, các nhà mã hóa không làm gì khác ngoài việc phá vỡ các giao thức như vậy, nó sẽ là một nhiệm vụ khó khăn.

SSL đã được phát triển bởi các chuyên gia trong lĩnh vực này và họ chắc chắn cũng nghĩ lúc đầu, rằng giao thức của họ hoàn toàn không thể phá vỡ. Nhưng sau đó đã có phiên bản 2, sau đó 3, sau đó TLS v.1, v1.1 và bây giờ 1.2.

Nếu bạn không có bất kỳ kinh nghiệm nào trong việc thiết kế giao thức bảo mật, bạn nên gắn bó với dòng chính và sử dụng TLS/SSL.

Bảo mật là một trong những lĩnh vực hiếm hoi có ý nghĩa và thực sự thú vị khi đi cùng với dòng chính, vì vậy tôi muốn nói rằng số tiền được thêm vào sẽ được chi tiêu tốt.

Edit:

Có lẽ tôi là một chút khắc nghiệt, và tôi thiếu một số giải thích là tại sao cách tiếp cận của bạn không thể cạnh tranh với một giao thức hơi phức tạp như TLS, vì vậy chúng ta hãy phân tích nó:

1) Làm thế nào bạn sẽ làm việc trao đổi chính? Để AES hoạt động trên cả hai đầu, bạn cần phải thực hiện Key Exchange, để mã hóa đối xứng, cả hai bên cần có cùng một khóa. Như bạn đã nói, bạn muốn tạo ngẫu nhiên trên máy khách - cho đến nay rất tốt. Vấn đề đầu tiên - bạn cần tạo một secure random number - nếu không, ví dụ: bằng cách sử dụng trình tạo số ngẫu nhiên Javascript tích hợp - kẻ tấn công có thể dự đoán các số ngẫu nhiên của bạn sau một thời gian.

2) Giả sử bạn đã nắm vững điều đó. Sau đó, vấn đề tiếp theo nảy sinh, làm cách nào bạn gửi khóa này đến máy chủ một cách an toàn, tức là thực hiện trao đổi khóa? Ở đó bạn sẽ cần một số hình thức xác thực trên phía máy chủ, nếu không chỉ là về bất cứ ai có thể áp đặt như máy chủ của bạn và thực hiện điều này:

  • lừa người vào gửi chìa khóa của họ đến máy chủ giả mạo của họ đầu tiên
  • sau đó chuyển tiếp phím máy chủ của bạn
  • máy chủ của bạn nghiêm túc sẽ gửi dữ liệu mã hóa với các thiết lập quan trọng
  • những kẻ tấn công sẽ đánh chặn dữ liệu đó và vui vẻ đọc bí mật của bạn bằng cách giải mã với khóa họ chỉ lấy trộm

3) Vì vậy, bạn cần xác thực máy chủ, ít nhất, nếu không xác thực máy khách, quá. Điều này sẽ ngụ ý rằng bạn cần một số dạng mã hóa khóa không đối xứng/khóa công khai để mã hóa/bọc khóa bằng khóa công khai của máy chủ để máy chủ có thể giải mã nó.

4) Khi bạn làm chủ được điều đó, bạn vẫn còn nhạy cảm với các hình thức tham gia nhiều hơn của các cuộc tấn công như replay attacks, man-in-the-middle-attacks, reflection attacks ...

5) Có lẽ bạn cũng muốn Perfect Forward Secrecy để khi một phím làm bị xâm phạm kẻ tấn công sẽ không có khả năng giải mã bất kỳ dữ liệu nào trong quá khứ. Bạn sẽ cần Diffie-Hellman (tốt nhất là ở dạng Elliptic Curve Cryptography) để đạt được điều này.

6) Cuối cùng nhưng không kém phần quan trọng, cơ chế phiên có thể cũng tốt để bạn có thể nhận các phiên trước đó với các khóa đối xứng đã được thiết lập để bạn có thể giảm tải trên máy chủ. nó một lần nữa bằng cách sử dụng các thuật toán khóa công khai một phần tài nguyên.

-> Thêm một vài tính năng khác, chẳng hạn như thương lượng một cách an toàn bộ thuật toán mà cả máy khách và máy chủ xác nhận để hỗ trợ và bạn sẽ thực hiện lại giao thức TLS. Xin lỗi nếu điều này có vẻ hơi châm biếm, nhưng tôi biết có vẻ như muốn cuộn các chương trình mã hóa của riêng bạn (nó cũng thú vị), nhưng cuối cùng bạn nên gắn bó với TLS: nó (tương đối) dễ sử dụng, nó chạy trên lớp truyền tải (vì vậy bạn có thể mã hóa các ứng dụng của mình như thể không có mã hóa nào cả) và tốt nhất là nó an toàn.

EDIT: Vâng, gần đây đã có một số cuộc tấn công, nhưng hầu như tất cả các cuộc tấn công đã khai thác "yếu tố con người" trong các giao thức này bằng cách tấn công các chứng chỉ khóa công khai mà quay lại giao thức (Comodo, DigiNotar, v.v.là các ví dụ nổi bật) hoặc các tính năng phức tạp hơn của giao thức như đàm phán thuật toán, vv, nhưng BEAST là lần đầu tiên TLS bị tấn công thành công ở cấp mật mã, điều này thật thú vị và đáng sợ cùng một lúc, bởi vì cuộc tấn công đó đã được biết đến với số some years bây giờ.

Tuy nhiên, với các bản sửa lỗi gần đây cho BEAST tại thời điểm này, tôi sẽ đặt cược rằng TLS vẫn là lựa chọn tốt nhất cho giao tiếp bảo mật trên web, đặc biệt khi so sánh với các giải pháp thủ công.

+10

+1: Tôi đã ngừng đọc sau khi tôi thấy mã javascript với mã hóa/giải mã và các phím .. – NotMe

+5

+1. Quy tắc số 1 về cách viết lược đồ mã hóa của riêng bạn: Không. –

+0

Tôi muốn +1 lại điều này. Tuyệt vời viết lên. – NotMe

3

Lời khuyên của tôi là gắn với SSL/TLS. Tôi nghĩ rằng điều này sẽ làm cho cuộc sống của bạn dễ dàng hơn và cũng cung cấp cho ngành công nghiệp giải pháp của bạn được công nhận sự tín nhiệm.

Thay vì địa chỉ IP tĩnh, bạn có thể sử dụng DynDNS (hoặc dịch vụ tương tự) với chứng chỉ tự ký không?

9

Ryan: Tôi đang nói điều này theo những gì tôi hy vọng là cách tốt nhất có thể: tiêu thụ bộ nhớ là tuyệt đối ít nhất trong số các vấn đề của bạn.

Không có gì an toàn về điều này. Không có gì. N.o.t.h.i.n.g.

Nó đã chết ngay từ lần gửi javascript đầu tiên ... Tôi không quan tâm các khóa của bạn dài bao nhiêu hoặc ngẫu nhiên muối là bao nhiêu.

Những gì bạn sẽ không ngăn ai đó ngồi trong quán cà phê với các gói mở bằng máy tính xách tay của họ ngăn chặn các khóa và có thể dễ dàng giải mã mọi thứ khác bạn chuyển qua lại. Heck, chỉ cần nhìn thấy những từ "mã hóa", "giải mã", và "chìa khóa" trong dòng sẽ là đủ để khơi dậy một ai đó quan tâm để lặn thêm cho vui (hoặc lợi nhuận ..). Đừng bận tâm khi xem một kết nối mở đột nhiên bắt đầu chuyển các phần của các gói được mã hóa và các phần khác trong suốt.

Nếu những gì bạn có có giá trị mã hóa thì sẽ đáng giá thêm $ 240/năm để làm đúng. Xin vui lòng, bước trở lại từ gờ và chỉ cần làm điều đó đúng.

5

Mọi người đều đã quá tiêu cực, và trong khi tôi chia sẻ niềm tin rằng bạn thân nên có lẽ không được làm điều này, hãy để tôi làm cho một số nhận xét chung:

Đối với một kênh an toàn bạn cần ba điều:

  • mã hóa dòng
  • trao đổi khóa
  • xác thực

Để mã hóa, bạn cần triển khai mật mã. Đó là doable.

Trao đổi khóa là điểm quan trọng: Cả hai đồng nghiệp cần phải biết rằng họ biết một khóa chung mà không ai khác có thể biết khóa chung. Có tồn tại các giao thức cho điều đó, và nó sẽ có thể thực hiện điều đó. SSL đang làm điều đó, ví dụ. Thực tế là bạn có thể đánh hơi một kết nối SSL và không tìm hiểu bất cứ điều gì cho thấy rằng nó có thể được thực hiện.

Xác thực là cần thiết để ngăn chặn các cuộc tấn công giữa người và điều này đòi hỏi một số loại trao đổi thông tin ngoài băng tần (như cuộc gọi điện thoại hoặc cơ sở hạ tầng PKI). Cho dù bất kỳ điều này thực sự hoạt động thực tế là rất gây tranh cãi, ngay cả đối với SSL. Vì vậy, về cơ bản nếu bạn có thể triển khai tất cả các thành phần đó qua HTTP, thì về nguyên tắc, có thể chạy truyền thông an toàn qua HTTP. Về đầu trang Sau khi tất cả, SSL đang làm điều tương tự, nó đang chạy một kênh an toàn trên một phương tiện không an toàn. Về cơ bản những gì bạn muốn là thực hiện SSL trong JavaScript. Kiểm tra aSSL, họ đã thử một cái gì đó như thế.

Các vấn đề liên quan