--> Đoạn này mình không hiểu lắm, ý bạn có phải là nếu mình muốn tìm một số nguyên tố có độ dài 500 bits là rất vất vả, và RSA dựa vào nguyên tắc này? Nếu vậy thì mình không đồng ý lắm. Trên thực tế, RSA không dựa vào bất cứ nguyên tắc nào liên quan đến số nguyên tố cả.

--> "điều này" = "việc tính toán số nguyên tố lớn rất vất vả"? Mình nghĩ chưa chắc, vì khi mã hóa hoặc giải mã có động gì đến số nguyên tố đâu. 

1. Chọn 2 số nguyên tố lớn p , và q , với p != q, lựa chọn ngẫu nhiên và độc lập.
2. Tính: n = p*q.
3. Tính: giá trị hàm số Ơle \phi(n) = (p-1)(q-1) .
4. Chọn một số tự nhiên e sao cho 1 < e < \phi(n) \, và là số nguyên tố cùng nhau với \phi(n) .
5. Tính: d sao cho d e \equiv 1 (mod (\phi(n)).

 

Tuy thế, việc tính toán hàm mũ và tính phần dư cho số cực lớn cũng là công việc không phải nhanh chóng, và việc chia mod n cho số cực to đó cũng không nhanh chóng gì cả. 

Mình lại không nghĩ như vậy. Trên thực tế thì những tác vụ như vậy cũng chẳng đáng kể gì. Để chính xác hơn, khi nói đến viêc thực hiện các tác vụ tính toán, chúng ta nên dựa trên "độ phức tạp thuật toán". Các tác vụ trên đều có độ phức tạp tuyến tính O(n).
 

- Việc xin cấp Certificate từ verisign sẽ diễn ra thế nào?
 

Thắc mắc thứ 2 là nếu có 2 servers chạy SSL mà chỉ dùng 1 cert được CA cấp được không? Câu trả lời cũng là "hơi khó" smilie chắc là không được.
Thắc mắc thứ 3 là 2 servers với 2 cert từ 2 CA khác nhau được không? Câu trả lời cũng là "hơi khó".
 

Giả thiết là không có load balance device có khả năng SSL đứng trước các webserver.
 

mrro nói rõ rồi, có gì "hơi khó" đâu để xài 1 cert cho 2 (hay nhiều server), miễn là chúng phục vụ cùng 1 domain.  

Giả thiết là không có load balance device có khả năng SSL đứng trước các webserver.
 

Phía trên tui có nêu giải pháp phần mềm là dùng Pound đó, không nhất thiết phải mua hàng khủng là F5, hehe. Thậm chí có thể dùng 1 server vừa làm load balancing vừa làm web server nhưng tốt nhất thì nên 3. Túm lại giải pháp rẻ tiền là pound.
Cũng như mrro nói, muốn biết 2 server, 2 CA khác nhau, chạy DNS round robin được không thì cứ lấy cái máy chủ ra chạy là biết ngay thôi mà

mrro nói rõ rồi, có gì "hơi khó" đâu để xài 1 cert cho 2 (hay nhiều server), miễn là chúng phục vụ cùng 1 domain.  

 

1 cert làm sao có 2 CA chứng nhận được hả bác? bác có nhầm lẫn chỗ nào không ạ?
 

À, nếu xài load balancer, giải pháp rẻ tiền ấy ạ, tớ ko biết pound là cái gì, tớ hay xài Apache (mod_ssl + mod_proxy + mod_balance), cái này có lẽ là rẻ nhất đó
 

---> cái này thì tùy thuộc vào cái path mà requests đi vào và cơ chế duy trì session khi truy cập xuyên qua https. Nếu em load balancing theo kiểu dùng DNS round robin cho 2 web servers chẳng hạn mà 1 cái thì mang verisign, 1 cái thì mang startCom thì sẽ có vấn đề.  

Vậy nếu mình dùng cái public key được sign với CA này và install lên nhiều webserver khác. Thì các webserver B,C,D này có "chịu" không?
 

Haha, cám ơn anh em đã cho ý kiến. Về việc thử 1 cert được cấp từ CA do CSR được generate từ 1 webserver duy nhất và dùng nó install cho trên nhiều webserver thì mình sẽ thử.
Nhưng phân tích 1 chút nhé. Ví dụ webserver generate ra CSR để gửi lên CA gọi là webserver A.

Khi đó WebServer A này tạo ra 1 cặp private/public key.
Cái public key thì gửi lên CA để họ sign vào đó và họ gửi lại cho mình để mình install vào webserver.

Vậy nếu mình dùng cái public key được sign với CA này và install lên nhiều webserver khác. Thì các webserver B,C,D này có "chịu" không?
 

Tiếp tục, chúng ta bàn tới đoạn bình luận này của anh conmale

---> cái này thì tùy thuộc vào cái path mà requests đi vào và cơ chế duy trì session khi truy cập xuyên qua https. Nếu em load balancing theo kiểu dùng DNS round robin cho 2 web servers chẳng hạn mà 1 cái thì mang verisign, 1 cái thì mang startCom thì sẽ có vấn đề.  

Xin mời mọi người. 

Tốt nhất, là sau khi cho cert vào webserver A, export cái cert+pub key+private key ra, thành 1 file .p12, rồi mang cái file này đi import vào đâu cũng được (web B, C, D). File p12 này cũng là để backup, vì nó cài vào bất kỳ server nào, server đó sẽ y chang webserver A.
 

---> cái này thì tùy thuộc vào cái path mà requests đi vào và cơ chế duy trì session khi truy cập xuyên qua https. Nếu em load balancing theo kiểu dùng DNS round robin cho 2 web servers chẳng hạn mà 1 cái thì mang verisign, 1 cái thì mang startCom thì sẽ có vấn đề.
 

Bạn thử vào đây:
https://ebanking.dongabank.com.vn/login.jsp
Sẽ thấy nó khác (cả cái thanh address bar).
Để cái which is run by xxx thì phải có Extended Validation. Cái Cert được ký dưới EV, sẽ ... mắc tiền hơn nhiều. Lúc đó, tên hiệu của mình cũng sẽ hiện lên rất đẹp.
Cert ký không có EV, thì chỉ xác nhận domain hoặc có thể có thêm cái O (organization) ở Subject của cert. Hết.
Có thể google nó tiết kiệm vài ngàn $ (có thể nhân cho nhiều server), nên nó không có cái đó, đơn giản vậy thôi. 

Hi !
Mình thấy một số trang web khi xem cái cert của nó "connection encrypted : high-grade enctryption(AES-256 256 bit) " . Tuy nhiên có những trang lại là "connection encrypted : high-grade enctryption(RC4 128 bit)"
Vậy chúng khác nhau như thế nào ? và cái nào bảo mật hơn cái nào ? Thân 

Trong này tớ không thấy chỗ nào đề cập tới AES-256 và RC4 . Vậy tại sao có sự khác nhau khi xem cert và cơ chế nào tạo ra sự khác nhau đó.
...
 

IIS default dùng RC4 để mã hoá
apache default dùng AES 256 để mã hoá

Đây là cái nhìn tổng quan của mình khi xem qua một số trang web và trước khi post bài thảo luận . Không biết điều này có chính xác không ? Nếu đúng thì chúng ta có thể tuỳ chỉnh ở đâu trên iis và apache ?

Mong các bác chỉ thêm  

vikjava wrote:

Trong này tớ không thấy chỗ nào đề cập tới AES-256 và RC4 . Vậy tại sao có sự khác nhau khi xem cert và cơ chế nào tạo ra sự khác nhau đó.
...
 

Không đề cập vì verisign chỉ ký cert chứ đâu có tạo cert, thuật toán nào là do người tạo và application dùng để tạo ra cert đó. 

thank mr.Bi.
IIS default dùng RC4 để mã hoá
apache default dùng AES 256 để mã hoá

Đây là cái nhìn tổng quan của mình khi xem qua một số trang web và trước khi post bài thảo luận . Không biết điều này có chính xác không ? Nếu đúng thì chúng ta có thể tuỳ chỉnh ở đâu trên iis và apache ?

Mong các bác chỉ thêm  

Mrro nói thế dễ gây cho các bạn chưa hiểu về SSL/TLS và cert.
Cert có quy định 1 thuật toán mã hoá và hash, nhưng đó là thuât toán mã hoá bất đối xứng dùng để xác nhận/ký/mã hoá cho cặp private/public key (RSA hay DSA + độ dài khoá), và hàm hash dùng để hash thông tin trong cert (MD5, SHA1, SHA256...). Độ dài khoá này cũng là cái quyết định giá tiền của cert và cả hệ thống chấp nhận được cái cert đó, ví dụ ký với độ dài 1024 hay 2048bit hoặc cao hơn.
Còn trong phiên SSL/TLS, thì sau bước bắt tay trao đổi giải thuật mã hoá và khoá (cái này giờ lại là thuật toán đối xứng và khoá dành cho thuật toán này: DES 56bit, 3DES 168bit, AES 256 bit, RC4 128bit...). server và client quyết định cái này, tuỳ theo khả năng và prefer của nó.
Không nhầm lẫn giữa 2 dạng đó. Không thì cứ giải thuật mã hoá là bla bla, nhầm lẫn. 

Mrro nói thế dễ gây cho các bạn chưa hiểu về SSL/TLS và cert.
Cert có quy định 1 thuật toán mã hoá và hash, nhưng đó là thuât toán mã hoá bất đối xứng dùng để xác nhận/ký/mã hoá cho cặp private/public key (RSA hay DSA + độ dài khoá), và hàm hash dùng để hash thông tin trong cert (MD5, SHA1, SHA256...). Độ dài khoá này cũng là cái quyết định giá tiền của cert và cả hệ thống chấp nhận được cái cert đó, ví dụ ký với độ dài 1024 hay 2048bit hoặc cao hơn.
Còn trong phiên SSL/TLS, thì sau bước bắt tay trao đổi giải thuật mã hoá và khoá (cái này giờ lại là thuật toán đối xứng và khoá dành cho thuật toán này: DES 56bit, 3DES 168bit, AES 256 bit, RC4 128bit...). server và client quyết định cái này, tuỳ theo khả năng và prefer của nó.
Không nhầm lẫn giữa 2 dạng đó. Không thì cứ giải thuật mã hoá là bla bla, nhầm lẫn. 

Bộ K1 được sinh ra trong quá trình chúng ta dùng IIS, Apache generate ra CSR (Certificate signing request) và gửi lên CA.