...
Tuy nhiên, nếu chúng ta có nhiều hơn 1 cái webserver cùng chạy song song và duy trì cái trang ebanking này
 

thangdiablo wrote:

...
Tuy nhiên, nếu chúng ta có nhiều hơn 1 cái webserver cùng chạy song song và duy trì cái trang ebanking này
 

--> thangdiablo nói rõ hơn chỗ này đi. Mục đích là để redundancy, load balancing, hay là gì?

PS: Tài liệu Licensing Verisign Certificates có đề cấp đến vấn đề này đấy.

 

Với trường hợp chúng ta chỉ có 1 webserver để duy trì cái trang ebank.abc.com thì đơn giản rồi. Tuy nhiên, nếu chúng ta có nhiều hơn 1 cái webserver cùng chạy song song và duy trì cái trang ebanking này thì
- Việc xin cấp Certificate từ verisign sẽ diễn ra thế nào?
- Việc tạo ra CSR chỉ cần làm trên 1 servers hay trên tất cả servers ?
- Mình phải mua mấy Certificate từ verisign?
- Common name lúc này có thay đổi hay không?
- Khi dữ liệu được encryption từ client tới servers thì verisign sẽ chứng thực cái Certificate này là không bị giả mạo ở khúc nào?

Mời mọi người thảo luận. Mọi người lưu ý tập trung vào vấn đề mình đang hỏi. Đừng lang bang sang vấn đề khác vì đề tài về CA này là rất rộng.
 

- Mỗi server tạo một CSR bởi vì mỗi server có private key riêng (tùy web service là cái gì nữa).
- Bao nhiêu servers thì bấy nhiêu certificates. Signed certificate là public key của từng server (có private key riêng).
- CN không cần phải thay đổi. Tuy nhiên, cần phải ghi nhận ngày giờ signed của từng certificate cho từng server để phân biệt chúng và renew chúng về sau.
- Khi dữ liệu được encrypted từ client tới server là sao? Ý em là clients (browsers) từ encrypt cái gì rồi gởi lên server? 

• dynamic hostname: mỗi thằng phải dùng một certificate riêng hoặc có thể dùng wildcard certificates (*.yourcompany.com)
• identical hostname: mỗi thằng phải dùng một certificate riêng hoặc mua dạng Licensed Certificate Option.

- Khi dữ liệu được encrypted từ client tới server là sao? Ý em là clients (browsers) từ encrypt cái gì rồi gởi lên server? 

Anh em cho mình hỏi thêm.
Ví dụ giữa các web server mình không có 1 thiết bị load blancing có khả năng generate ra CSR dạng như Citrix chẳng hạn mà đơn giản chỉ là sử dụng network load balance có sẵn trên Windows.

Như vậy việc generate ra CSR phải thực hiện trên từng WebServer. Nếu WebServer thứ 1 mình dùng Certificate của Verisign, WebServer thứ 2 mình muốn dùng Certificate của StartCom. Yêu cầu là common name không thay đổi. Như vậy có được không?


 

Hi anh conmale,

Bên em dữ liệu là real time nên em không có suy nghĩ tới giải pháp là reverse proxy 

Reverse proxy không cache thì vẫn không ảnh hưởng gì đến dữ liệu real time cả. Đừng nghĩ "proxy" là phải cache. 

Về việc trình CA chỉ đóng vai trò khi trình duyệt kiểm tra xem certificate này có bị revoked hay chưa thì mình hoàn toàn đồng ý.

Có 4 thông tin mà trình duyệt sẽ kiểm tra khi truy cập vào 1 trang web ứng dụng SSL như mrro đã nói.
Tuy nhiên mình có thắc mắc là nếu trình duyệt không thực hiện bước kiểm tra revoked thì nếu vì 1 lí do nào đó tổ chức bị CA revoked mà trình duyệt vẫn báo trusted thì sao?  

Vì lúc này khi client truy cập (đăng nhập user name + password) nguyên đống thông tin này sẽ được mã hóa bằng session key và session key lại được mã hóa bằng public key (cert) của Server. Và cert này sẽ được CA kiểm định xem có an toàn hay không. Nếu nó đi tới Server A thì server A có private key để mà giải mã.
 

Các server khác không có private key thì sẽ ứng xử thế nào hehe
 

mình có câu hỏi, làm sao các bạn chứng minh được là không tồn tại 2 cặp key: public1/private1 và public2/private2 sao cho public1=public2 và private1!=private2
 

Ngược lại nếu muốn dùng 1 cert và chỉ cần 1 CSR thì sẽ set cặp public/private key duy nhất cho tất cả các server (liệu chỗ này mình chỉ cần set public key thôi là đủ không nhỉ, vì thuật toàn mã hóa public key sẽ tự tìm ra private key tương ứng)...

 

he he he nếu mà cái chỗ màu đỏ đúng thì còn gì hệ mã khóa công khai nữa bạn. ngược lại thì đúng, nghĩa là có private key thì sẽ tính được public key, nhưng mà nhìn vào public key không thể nào tính được private key.
 

bạn có học qua lý thuyết số thì sẽ thấy việc chứng minh này rất dễ dàng. giải thích cái này dài dòng, nằm ngoài nội dung của chủ đề này, nên mình không viết ra ở đây.
 

gamar wrote:

Ngược lại nếu muốn dùng 1 cert và chỉ cần 1 CSR thì sẽ set cặp public/private key duy nhất cho tất cả các server (liệu chỗ này mình chỉ cần set public key thôi là đủ không nhỉ, vì thuật toàn mã hóa public key sẽ tự tìm ra private key tương ứng)...
 

he he he nếu mà cái chỗ màu đỏ đúng thì còn gì hệ mã khóa công khai nữa bạn. ngược lại thì đúng, nghĩa là có private key thì sẽ tính được public key, nhưng mà nhìn vào public key không thể nào tính được private key.
 

liệu biết (n, d) có thể tính được e hay không? Đương nhiên lúc này e phải thỏa mãn những tính chất khi người ta chọn e trong thực tế, ví dụ như e phải rất nhỏ.
 

@StarGhost: mình đang nói đến thông tin nằm trong file chứa private key, còn SG lại nói về lý thuyết. 

Dẫu vậy đây cũng là một vấn đề hay, mình không biết Elgamal và Cramer-Shoup nên không dám nói bừa, mình có biết chút ít về RSA nên thử bàn xem: liệu biết (n, d) có thể tính được e hay không? Đương nhiên lúc này e phải thỏa mãn những tính chất khi người ta chọn e trong thực tế, ví dụ như e phải rất nhỏ.  

mrro wrote:

@StarGhost: mình đang nói đến thông tin nằm trong file chứa private key, còn SG lại nói về lý thuyết. 

À à, thế mình lại sai rồi. Cái này mình không nhớ rõ. Sau này mình không bàn luận bừa nữa.
 

mrro wrote:

Dẫu vậy đây cũng là một vấn đề hay, mình không biết Elgamal và Cramer-Shoup nên không dám nói bừa, mình có biết chút ít về RSA nên thử bàn xem: liệu biết (n, d) có thể tính được e hay không? Đương nhiên lúc này e phải thỏa mãn những tính chất khi người ta chọn e trong thực tế, ví dụ như e phải rất nhỏ.  

Hì hì, nếu nói như mrro thì chả cần có private key mình cũng biết e là gì (với xác suất cao), vì hầu hết bây giờ người ta toàn dùng e = 65537. Lí do: i) 65537 đủ nhỏ mà cũng đủ lớn (để encrypt nhanh) ii) 65537 = 2^16+1 (để tính toán nhanh) iii) 65537 là một số nguyên tố (để chọn p,q nhanh).
Còn Elgamal và Cramer-Shoup thì hiển nhiên không được, vì mapping từ PubKey Set -> PriKey set không phải là one-to-one. 

Trong RSA, có private key ko tính toán được public key, và ngược lại, 2 con số này (2 cái key thực ra là 2 con số nguyên tố), nó quan hệ toán học với nhau đối xứng thì mới thành cặp key, nếu không phải thì ko thể thành cặp. Nếu xét về mặt toán thì cái nào là public, cái nào là private cũng được, quan trọng là giữ bí mật cái nào thì cái đó là private key, vậy thôi. (tham khảo http://en.wikipedia.org/wiki/RSA ).
Nguyên lý của nó, là bạn mã hoá bằng public thì giải mã bằng private, và ký bằng private (thực chất là mã hoá chuỗi hash của plain text), sẽ giải mã được bằng public, so cái chuỗi hash được giải mã đó với hash của plain text nhận được thì biết là đúng chữ ký hay không.
Hàm của nó kiểu:
e = c(p,pub)
=> p = c(e,pv).
<=>
e = c(p,pv)
p = c(e,pub)

Trong đó: e = bản đã mã, hoặc ký, p = plain, pv: private, pub = public. c là hàm mã hoá.

Về việc ko thể tính toán, nói đúng hơn ko phải ko tính ra được, mà là thời gian tính nó rất dài với năng lực của máy tính hiện tại (kể cả siêu máy tinh) thành ra là impossible. Tỉ dụ nếu độ dài 512bit (số 512bit độ dài, to lắm đấy, so với máy tính 64bit thì biết), ng ta nói rằng một số siêu máy tính trên thế giới đã có thể tính toán được ra cặp đối xứng đó, trong vòng 1 vài năm. Nhưng, với 1024, 2048 hoặc hơn, thì phải hàng ngàn, triệu năm.
RSA dựa vào nguyên tắc là việc tính toán ra số nguyên tố cực lớn là một việc cực kỳ vất vả. Nếu bẻ gãy được việc này, giảm thời gian đó xuống thì sẽ giải mã được RSA.
Cũng vì điều này, giải mã, mã hoá bất đối xứng như RSA, hay cả DSA là một việc tốn kém năng lực của máy tính, người ta không dùng nó để mã hoá cả 1 đoạn text dài, chỉ mã hoá hoặc ký vào symetric key hay là hash thôi, hay ký trong certificate hash. Symetric key này sẽ tiếp tục làm cái việc là mã hoá plain text bằng 1 block cipher có tốc độ cao hơn. Session key chính là Symetric key, lộ cái này thì phiên SSL cũng coi như là bị giải mã.