The EFF SSL Observatory is a project to investigate the certificates used to secure all of the sites encrypted with HTTPS on the Web. We have downloaded a dataset of all of the publicly-visible SSL certificates, and will be making that data available to the research community in the near future.

This project is not fully launched yet, because we are currently engaging in vulnerability disclosure for around 28,000 websites that we observed to be using extremely weak private keys generated by a buggy version of OpenSSL.

 

* In addition to the implausibly large and diverse group of CAs you trust, you also completely trust all the intermediary signers they they've signed. Including, of course, DHS (slide 42). (See also: Soghoian and Stamm, "Certified Lies".) Windows and Firefox trust 1,482 CA certs (651 organizations).

* Of 16 M IPs listening on 443, 10.8 M started SSL handshake; of those, 4.3 M used CA-signed cert chains (slide 14). Thus, the majority of servers use "invalid"/invalid/self-signed certs.

* The invalid certs contain all kinds of bad stuff (see slide 16).

* The valid certs contain all kinds of bad stuff (see the rest of the slide deck).

* CAs re-use keypairs in new certs to prolong the effective life (slide 28).

* Many CAs sign reserved/private names. Several CAs have signed e.g. 192.168.1.2. That host is certified to live in many countries by many CAs. One CA thinks its identity is the same as a public/routable IP.

* The single most often signed name is "localhost" (6K distinct certs for that subject name). Many CAs have signed that name many times; a few CAs only signed it once. This suggests many CAs don't even track the names they've signed to make sure they don't get tricked into signing a name twice. Never mind the fact that they shouldn't be signing private names in the first place...A colleague of mine got a CA-signed cert for "mail".
Could that be a problem?

* Your browser trusts two signing certs that use a 512-bit RSA key (slide 32).

* The bad Debian keys are not dead, and 530 are CA-signed. 73 of the 530 are revoked.
 

H3x4 wrote:

Còn vấn đề cuối cùng trong bài của bạn ducnguyen có nhắc tới đó là việc tham gia diễn đàn, một bài viết ra, một câu bình luận sẽ luôn luôn gặp phải những suy nghĩ và phản ứng trái chiều, sẽ có lợi cho một số và không có lợi cho số khác, người này nói nó đáng để học tập nhưng người khác lại nói đó chỉ là sự nông cạn hay "quăng bom", nó giống như một xã hội thu nhỏ vậy, anh conmale có thể chia sẻ một chút nguyên tắc của mình khi đối diện với những vấn đề như vậy không?
Cám ơn mọi người!
 

Theo anh nghĩ, không riêng gì ngành CNTT mà bất cứ ngành nào, khi một ý tưởng, cảm nhận, quan điểm... được nêu ra thì chắc chắn phải có ít nhất là 2 luồng bênh và chống được hình thành. Đặc biệt nếu những ý tưởng và cảm nhận ấy không được trình bày và biện chứng một cách khoa học, một cách chính xác và có lý lẽ thì 2 luồng bênh và chống càng gia tăng bởi vì nó mở cửa ra cho những suy luận và diễn giải ở nhiều góc độ khác nhau. Dù gì đi chăng nữa, đó là hiện tượng nên có bởi vì đó là dấu hiệu khoẻ mạnh của xã hội: biện và phản biện.

Khi đưa ra một vấn đề gì đó (xuyên qua bài viết chẳng hạn), luôn luôn sẵn sàng đón nhận những chỉ trích tệ hại nhất cũng như những cổ vũ ồn ào nhất bởi vì đây là chuyện chắc chắn không thể tránh khỏi. Thật ra, nếu lấy lý do rằng mình viết bài và "bị" phản ứng trái chiều nên không muốn viết nữa thì đó là tư duy thụ động và thiếu sự vững vàng trong quan điểm của cá nhân. Trái lại, hãy cám ơn những phản ứng trái chiều đó bởi vì đó chính là nguồn phát triển tri thức và khả năng tư duy.

Nhận ra cái sai, cái thiếu sót đã là khó nhưng chấp nhận cái sai, cái thiếu sót thì càng khó bội phần và để có cơ hội nhận được cái sai, cái thiếu sót để đi đến chỗ chấp nhận cái sai, cái thiếu sót thì việc cần thiết đầu tiên là: nêu ra ý kiến (xuyên qua bài viết chẳng hạn). Để làm được điều này, chính bản thân mình phải trung thực, tỉnh táo và dũng cảm đón nhận phản hồi. Từ đó, mình mới có thể đi xa hơn. Những góp ý dạng "quăng bom" chỉ nhằm mục đích phá hỏng hoặc làm lạc đề vấn đề được đưa ra không chóng thì chày nó cũng sẽ bị loại bỏ. Nếu chính mình bị cuốn vô cõi "quăng bom" thì đó là do mình không tự chủ và không tập trung vào những giá trị mình đưa ra. Tuy nhiên, có những góp ý mới xem qua thì na ná "quăng bom" nhưng thật ra lại là những góp ý tạo kích thích cho suy nghĩ và phản biện. Bởi vậy, nên tỉnh táo mà xét tình hình. 

Tôi định không viết gì nhỉ?

Tôi định viết gì nhỉ? Trả lời cho câu hỏi này khó quá đi, có quá nhiều thứ để viết (nên chẳng biết nên viết cái gì). Hay là thử trả lời cho câu hỏi: tôi định không viết gì nhỉ?

Haha chỉ đổi câu hỏi có một chút xíu mà đã thấy bối rối lắm rồi nhe. Nếu tôi viết ra đây những gì tôi không định viết ra, vậy liệu những gì bạn sắp biết có phải thật sự là những điều tôi không định nói cho bạn biết? Chắc chắn không, bởi tôi đã nói cho bạn biết rồi còn gì nữa. Bạn đã thấy được sự mâu thuẫn? Tôi sẽ chẳng nói cho bạn biết những gì tôi không định nói đâu, tôi cũng không ép bạn kể cho tôi nghe những điều bạn không định kể. Bí mật nên được tôn trọng bởi vì chúng làm nên sự hấp dẫn ở mỗi con người, phải không bạn?

Nhưng ở đây thì khác, tôi không bàn về "bí mật", chữ "định không viết" của tôi dùng để chỉ những thứ tôi nghĩ tôi không nên viết trên blog của mình. Viết một cái blog giống như sống thêm một cuộc đời mới, nơi mỗi ngày tôi lại thấy mình lớn lên thêm một chút khi nhận ra cái entry ngày hôm qua, hôm kia hay ngày nọ của tôi thật ngớ ngẩn, ấu trĩ, chẳng "người lớn" tí nào. Bạn có bao giờ trải qua cảm giác đó chưa? Lần giở những cuốn sổ hay ngồi hồi tưởng lại những điều đã qua rồi bất chợt thấy mắc cỡ quá, sao hồi đó mình có thể ngớ ngẩn và ấu trĩ đến như thế được nhỉ? Mà cái "hồi đó" có khi chỉ mới ngày hôm qua, hay tuần rồi, thậm chí ngay sau khi bấm cái nút submit. Rồi nghĩ vẩn vơ, không biết có ai khác nhớ mấy cái "phi vụ" đó không trời? Rồi ngồi cười khì khì một mình như bị tâm thần. Như tôi bây giờ nè. Đúng là bỗng nhiên mà họ lớn.

Cách đây vài phút, tôi nghĩ đến chuyện lập ra danh sách những điều tôi không nên viết trên blog, những điều sẽ làm tôi trở thành một kẻ ngớ ngẩn và ấu trĩ (trong suy nghĩ của bạn). Nhưng lại có một mâu thuẫn ở đây, nếu tôi không muốn cho bạn biết tôi là một kẻ ngớ ngẩn, thế thì làm sao tôi lớn lên hay trưởng thành hay chính chắn thêm được nữa? Mà tôi không lớn lên, không trưởng thành hay chính chắn thêm thì một ngày nào đó bạn sẽ nhận ra ngay tôi là một kẻ ấu trĩ, một đứa bé trong hình hài người lớn. Thế nên một danh sách những điều ngớ ngẩn không nên viết là hết sức vô bổ. Tôi sẽ tiếp tục viết, với một hi vọng, ngày mai hay ngày mốt hay một năm sau, đọc lại chúng, tôi thấy mình lớn hơn.

Nhưng lớn mãi àh, phải có điểm dừng chứ? Hồi còn 1x, tôi cứ nghĩ chắc đến khi tôi lên hàng 2x, sẽ không còn mấy cái vụ nhớ-rồi-mắc-cỡ-rồi-lớn-tiếp nữa đâu. Vậy mà nó vẫn xảy ra đều đều, càng lớn càng ít nhưng vẫn có chứ không hết hẳn. Không biết đến khi nào mới thật sự hết nhỉ? Đến khi nào tôi mới thật sự lớn hẳn luôn, tạm gọi là trưởng thành, chứ không còn cái kiểu lưng chừng xuân thế này? Đến khi cưới vợ hay đến khi làm bố hay nó sẽ tiếp tục như thế đến chừng nào tôi ngủm củ tỏi? Tôi ngờ chắc cũng còn lâu lắm, nên bắt đầu lớn ngay từ hôm nay là vừa!

Oops, tôi viết cái gì thế này? Đây không phải là những điều tôi định nói với bạn đâu!
 

Ngoài ra, mình cho rằng có một thứ còn yếu hơn PKI và WoT rất rất nhiều mà nó vẫn được dùng hết sức phổ biến, mà hình như chưa bao giờ bị than phiền về vấn đề security. Mình để bạn đoán thử coi nó là cái gì?
 

Điều này bạn có thể đọc các tài liệu liên quan đến mật mã hoá (cả thế giới đã công nhận RSA với 4096 bit và SHA-128, 256 là không thể phá được).
Mình sử dụng khái niệm gần tuyệt đối bởi hiện tại nó là không phá được, tuy nhiên tương lai thì không ai dám chắc cả.
 

Bạn muốn nói đến việc giả mạo cert của root dựa vào lỗ hổng sử dụng MD5? Bạn cũng biết MD5 đã không còn an toàn, cho nên nó không được sử dụng trong các hệ thống CA mới xây dựng gần đây (chủ yếu các CA có từ khoảng năm 200).
Cho nên cái CA bạn nói nó không ngon lành đâu bạn.
 

Tuy nhiên, chứ ký có an toàn không phụ thuộc vào nhiều nhiếu tố, và CA là một yếu tố quan trọng. Nhờ CA mà chữ ký của người dung an toàn hơn ở các góc độ sau đây (ở tầm ứng dụng thực tế và vĩ mô hơn một tí so với các công thức thuật toán):
- Không có CA, các chữ ký sẽ không có chút giá trị nào (và chắc chắn cũng chẳng an toàn vì nó hoàn toàn có thể bị giả mạo - không có CA chẳng có gì để kiểm soát được việc này).
- Không có CA, không ai chứng thực cho cái khoá public của user là của họ cả. Do vậy, độ an toàn của cái chữ ký cũng chẳng có ý ngĩa nữa.
- Tất nhiên, chữ ký được tin tưởng rộng rãi hơn
- ... tạm thời là thế,
 

Vậy nên, có thể khẳng định chữ ký của CA (đạt tiêu chuẩn kỹ thuật) sẽ có độ bền vững gần như tuyệt đối (cả về thuật toán, mật mã hoá, an toàn vật lý, con người) - nó khác chữ ký của user thông thường là ở chỗ đó (chữ ký cuả user có thể bị giả mạo nếu dùng khoá không tốt (độ dài, thuật toán,...)

P/s: không phải vô lý mà các CA lớn họ được tin tưởng rộng rãi, họ phải đạt các tiêu chuẩn an toàn kỹ thuật cực kỳ khắt khe của các hiệp hội kiểm định (Webtrust,...),
Bạn có thể tạo một CA, và cấu hình các tham số tuỳ thích (ví dụ dùng MD4, MD5 chẳng hạn), khi đó CA của bạn sẽ không an toàn - trong trường hợp đó dù cho người dùng thuộc CA của bạn có thực hiện các biện pháp an toàn nào nữa thì cũng không còn ý nghĩa.
 

Một sơ đồ chữ ký là một bộ ba thuật toán xác suất chạy trong thời gian đa thức (Gen, Sign, Verify) thoả mãn những điều kiện sau đây:

1. Thuật toán sinh khoá Gen nhận vào một hệ số an toàn (security parameter) 1^n, và xuất ra một cập khoá (pk, sk). pk được gọi là khoá công cộng, còn sk được gọi là khoá riêng tư. Để thuận tiện, chúng ta giả sử pk và sk đều có chiều dài ít nhất là n, và n có thể được xác định từ pk và sk.

2. Thuận toán ký Sign nhận vào một khoá riêng tư sk và một thông điệp m thuộc về {0, 1}*. Nó xuất ra một chữ ký s, và chúng ta ký hiệu là s <-- Sign(sk, m).

3. Thuật toán xác định Verify nhận vào một khoá công cộng pk, một thông điệp m và một chữ ký s. Nó xuất ra một bit b, với b = 1 nghĩa là đúng, b = 0 nghĩa là không đúng. Ký hiệu: b := Verify(pk, m, s).

Với mọi n, mọi cặp (pk, sk) xuất ra bởi Gen(1^n), và với mọi m thuộc về {0, 1}*, điều này phải luôn thoả: Verify(pk, m, Sign(sk, m)) = 1

Nếu (Gen, Sign, Verify) thoả điều kiện với mọi cặp (pk, sk) tạo ra bởi Gen(1^n), thuật toán Sign chỉ được xác định với các thông điệp m thuộc về {0, 1}^l(n) (và Verify xuất ra 0 với mọi m không thuộc về {0, 1}^l(n)), thì chúng ta nói rằng (Gen, Sign, Verify) là một sơ đồ chữ ký cho các thông điệp có chiều dài l(n).

 

* Gen: khi nhận vào 1^n thì chạy GenRSA(1^n) để nhận (N, e, d). Khoá công cộng là (N, e) và khoá riêng tư là (N, d).

* Sign: khi nhận vào sk = (N, d) và một thông điệp m thuộc về Z*N, tính s theo công thức: s := [m^d mod N].

* Verify: khi nhận vào một pk = (N, e), một thông điệp m thuộc về Z*N, và một chữ ký s thuộc về Z*N, xuất ra 1 khi và chỉ khi: m = [s^e mod N]

trong đó GenRSA là thuật toán xác suất chạy trong thời gian đa thức, nhận vào 1^n và xuất ra modulus N là tích của hai số nguyên tố có chiều dài n-bit (có thể sai với xác suất không đáng kể), và một cặp số nguyên e, d thoả điều kiện:

* 1 < e < phi(N), và gcd(e, phi(N)) = 1

* ed = 1 mod phi(N)

với phi(N) là hàm Euler totient.

 

Đồng ý với bạn và bạn SG. Tuy nhiên, bạn có thể giải thích tại sao rất nhiều tài liệu có nguồn gốc khá đáng tin lại định nghĩa theo cách kia. Ví dụ: http://www.answers.com/topic/digital-signature
 

Trong chủ đề này, giả sử chúng ta chỉ bàn đến RSA signature scheme cho cụ thể nhé.

Và nó cũng đã được chuẩn hoá rồi đấy bạn, nếu mình không lầm thì đó là ISO 9796 và dòng PKCS# cũng được công nhận là các chuẩn rồi đấy chứ bạn (điểm này mình cũng không chắc lắm).

 

Giá trị hàm băm được sử dụng trong khi tạo chữ ký số phải tạo bởi thuật toán an toàn (SHA-1, 2,...). Trong phạm vi các dữ kiện đưa ra trong câu hỏi, thì việc xác thực và đảm bảo tính toàn vẹn chỉ có thể thông qua việc mã hoá và tạo giá trị hash. Do đó, nếu đảm bảo an toàn 2 bước trên thì thông điệp là toàn vẹn và xác thực.
 

Chữ ký điện tử (digital signature) là đoạn dữ liệu ngắn đính kèm với văn bản gốc để chứng thực tác giả của văn bản và giúp người nhận kiểm tra tính toàn vẹn của nội dung văn bản gốc

--> Vấn đề cơ chế nào để đảm bảo rằng dữ liệu không bị thay đổi!.
 

Đoạn dữ liệu có thể bị thay đổi nhưng nó không thể mã hoá trở lại bằng khoá bí mật của người ký (một trong các công đoạn "ký" là hành động mã hoá đoạn dữ liệu này bằng khoá bí mật của người ký).
 

Thanks ,
PS cái đó mục đích của mình chỉ là úp lên thôi  

Chào anh, rất vui vì nhận được phản hồi của các anh. Ý em là ở đoạn 2.2 trong papers của anh có viết: gửi rất nhiều ciphertext tới một oracle nào đó và nhận thông báo lỗi chúng ta có thể đoán được là nó có phải padding oracles không phải không ? Như vậy:

đây có phải là chosen ciphertext attack không ạ?
Và tại sao lại có báo lỗi đó? 

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 đó.