@mrro

Xin ý kiến của mrro về nhận định ở trong blog post này http://vincent.bernat.im/en/blog/2011-ssl-dos-mitigation.html

Theo đó thì với tỷ lệ CPU giữa client : server thì việc client có thể làm tốn CPU của server khá nhiều. Như vậy thì chừng vài chục máy trạm là có thể làm quá tài server? DOS ở đây sẽ là DOS về CPU chứ không còn là network nữa.
 

mrro wrote:

MrKhoai wrote:

HTTPS không phải mặc định là tại vì thêm chữ "S". Một chữ thôi nhưng server và client phải làm việc nhiều lằm.
 

anh không nghĩ là server và client phải làm việc quá nhiều. nhiều site lơn trên thế giới bây giờ đã triển khai mặc định HTTPS cho nhiều dịch vụ lớn của họ. em xem thêm http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html.

-m  

Gần đây em đang bị 1 vấn đề về SSL trên website của mình

Nếu sử dụng các link internal mình có thể format thành "https" được. Nhưng nếu trong website có 1 link external format là "http" thì trình duyệt sẽ báo lỗi cert.

Ví dụ như Gmail cũng hay bị báo lỗi như thế này

Theo em nghĩ "https" sẽ được mở khi chúng ta vào những link yêu cầu nhập thông tin cá nhân trên 1 website là hợp lý nhất vì những trang đó ít khi kèm các link external ( ví dụ như : login, register... ) 

HTTPS không phải mặc định là tại vì thêm chữ "S". Một chữ thôi nhưng server và client phải làm việc nhiều lằm.
 

Đến giờ mới biết được anh Thái là admin tại đây. Chưa đủ trình độ để đọc bài của anh nhưng cũng đánh giấu, say này sẽ đọc. Cám ơn anh đã bỏ thời gian viết những bài viết hữu ích như vậy, chúc anh sức khoẻ.
 

Em đang là sinh viên năm 3 ngành quản trị mạng .Thực sự từ khi bước chân vào học CNTT là em đã thấy mình chọn sai con đường rồi ,lúc đó tính thi lại nhưng mà đã già quá(e sinh năm 88 ) nên thui .Bây giờ có thể nói là "Đâm lao thì phải theo lao thôi " nhưng dù sao em cũng không tính đi tới cùng với ngành này .Chỉ mong sao ra trường kiếm đủ cơm ăn ,rồi làm thêm 1 việc khác để có chút dư giả .E xin hỏi các bác là nếu e học quản trị mạng ,e học quản trị hệ thống ,thì cần phải học những gì để sau ra trường làm được (không cần làm giỏi )miễn sao người ta không đuổi việc mình .e không muốn học lan man tại vì vốn dĩ e đã không thích rồi nên e chỉ muốn tập trung vào những gì cần thiết thôi .E mong các bác giúp đỡ nhiệt tình .
 

Em biết là KHOÁ RIÊNG ko dùng để mã hoá, nhưng theo em tìm hiểu, thì giả sử B "ký" bằ PRIVATE-B của nó và gửi cho A. và A thẩm định lại bằng cách giải mã bằng PUBLIC-B để so sánh.


như vậy theo em hiểu là mã hoá bằng P giải mã bằng Q , và mã bằng Q thì giải mã bằng P phải ko ạ.

 

The TLS exploit is a neat fusion of two streams in vulnerability research: Cryptanalysis and client-side attacks. In this case, a known client-side problem–namely (that) Web sites are not shielded from one another–is used to break an assumption in cryptography–that a user’s computer will not attack the user.

Users already need to trust all the Web sites they are visiting due to vulnerabilities in their browsers (“drive-by exploits”) and in trusted Web sites (“tab-nabbing”). The new exploit strongly reminds us of this rule.
 

Bản rõ được ký hiệu là M, bản mã là C. Bản rõ được chia ra thành m khối P_1, P_2,...,P_m. Các khối này sẽ được mã hóa thành C_1, C_2,...,C_m.
Hàm mã hóa của mã khối là E_k, trong đó k là khóa. Tương ứng, hàm giải mã là D_k.
Viết X = {X_1}|{X_2}|\cdots|{X_m} nghĩa là kết nối các khối X_i lại với nhau để tạo ra khối X.
Vector khởi tạo (initialization vector) được ký hiệu là IV.

Mã hóa
C_i = E_k(P_i), i=1,..,m
C = C_1|C_2|...|C_m
Giải mã
P_i = D_k(C_i), i=1,..,m
M = P_1|P_2|...|P_m

Mã hóa
C_0 = IV
C_i = E_k(P_i \oplus C_{i-1}), i=1,..,m
C = C_0|C_1|C_2|\cdots|C_m
Giải mã
P_i = D_k(C_i) \oplus C_{i-1}, i=1,..,m
M = P_1|P_2|\cdots|P_m

Phil Rogaway observed that CBC mode is not secure against chosen-plaintext attack if the IV is known or can be predicted by the attacker before he choses his plaintext [1]. Similarly, CBC mode is not secure if the attacker can observe the last ciphertext block before choosing the next block of plaintext, because the last block of ciphertext essentially serves as the IV for the rest of the message.

The attack itself is very simple. Remember that in CBC mode, each plaintext block is XOR'ed with the last ciphertext block and then encrypted to produce the next ciphertext block. Suppose the attacker suspects that plaintext block P_i might be x, and wants to test whether that's the case, he would choose the next plaintext block P_j to be x XOR C_(i-1) XOR C_(j-1). If his guess is correct, then C_j = Encrypt(P_j XOR C_(j-1)) = Encrypt(P_i XOR C_(i-1)) = C_i, and so he can confirm his guess by looking at whether C_j = C_i. [...]

[1] http://www.cs.ucdavis.edu/~rogaway/papers/draft-rogaway-ipsec-comments-00.txt
 

@jin9x

@mrro
b3. việc phát biện bộ quét virus có thể sử dụng 1 cách đơn giản là sử dụng các mẫu đặc biệt mà 1 engine này phát hiện, nhưng engine khác không phát hiện (virustotal?). Không dễ, nhưng tui nghĩ là khả thi. Về phía defense, sử dụng 2 engine hoặc là sử dụng 1 engine, nhưng hiển thị cho user là engine khác cũng có 1 ít tác dụng (ví dụ yahoo nói sử dụng Norton, nhưng sao biết chắc là nó sử dụng Norton?)

regex viết nhanh (chưa đầy đủ) của url /^https?:\/\/[a-zA-Z0-9_\.-]+\/[a-zA-Z0-9_\.-\/~]+/
biểu thức chính quy vẫn có rủi ro đối với bản thân parser & execution engine của regex (lỗi BO?) . Còn một vấn đề nữa là hình như url giờ có utf8 (non-English) nên regex sẽ khá phức tạp nếu muốn user có thể sử dụng được dịch vụ ở mọi nơi.

tui có 1 ý nghĩ là sao ko dùng các technique của AI: machine learning, pattern recognition (neuron network, empirical analysis, ....) để cho điểm và đánh giá nội dung attachment. Ví dụ sau khi phân tích, ta có điểm 4/10 -> hiện ra visual notification cho user là attachment này likely - unlikely harmful để tự bản thân user chọn -> adjust điểm (giống crowd sourcing)
 

4a. Cho GMail request đến server của mình, ở server mình cho sniff để lấy những thông tin của kết nối đó, sau đó dựa vào những thông tin đó để "đoán" (nhưng chắc là đoán không ra vì nhiều khả năng Gmail sử dụng công cụ riêng của họ)

4b. Để kiểm tra thì chỉ càn cho nó "xem" một đoạn javascript có chức năng gửi một request đến server mình và cho sniff thôi.
có request => đoạn js được thực thi => "cái gì đó" hiểu được js

--->Vấn đề này có thể nảy sinh nhiều vấn đề bảo mật khác, có thể áp dụng khai thác XSS, CRSF ... vào js mà
 

b3. cái vụ bo này thì tui chỉ tạm biết là nếu giờ cho load file đủ lớn chứa toàn là AAAA hay gì đó, nếu gmail temporarily out of service sau khi attach -> crash service -> có khả năng stack/mem bị overwrite ở đâu đó -> rồi ROP hay gì đó nữa.

chi tiết hơn tui phải nghiên cứu thêm về RoP và đọc thêm về BO mới rõ được, còn trên chỉ là nguyên lý tui nhớ mang máng

@gamma95: ý 2&3 rất hay -> sẽ phải sanitize user input. Mà thường nguyên lý là không bao giờ tin user input nên việc kiểm tra bad url sẽ được thực hiện đầu tiên -> việc malicious server host valid url sẽ có hiệu quả hơn.

nhân tiện đặt thêm câu hỏi: url valid trong trường hợp này sẽ là gì? nếu kiểm tra valid url (http/https only, no port, no user@pass) thì có thể fix được một số vấn đề đang thảo luận hay không?
 

1. Cho một cái URL dạng live streaming, máy chủ google cứ tải cái file đó hoài và crash vì hết đĩa

2. Cho 1 cái URL để download một cái file có tên là \..\..\..\..\..\boot.ini chẳng hạn, nếu có có dùng AV để quét hoặc gì đó hoặc attachfile lên cho mềnh thì ngon.

3. URL nó hỗ trợ protocol nào thì mình test cái đó, VD mình nhập file:///etc/passwd chẳng hạn, file attach mình nhận đc sẽ là file /etc/passwd của google.

vấn đề giờ là lúc này gmail coi như là 1 client và đang "duyệt web" của attacker(vì attackers đang bắt gmail phải chạy những URL mà mình input vào ), tiếp theo là:

4. Tui cho gmail vô cái link http://gamma-dep-trai.com và sniff lại thử coi gmail đang dùng "cái gì" để __browse__ vô web của tui. Việc thứ 2 là coi "browser" của gmail nó có chạy được mấy cái scripting language ở client như js, vb, flash ... như những browser khác hay ko. Nếu con crawler thông minh quá có thể chạy đc cả js chẳng hạn thì có nhiều chuyện để nói lắm nha

5. Khi tui biết cái ip của con crawler gmail rồi thì vấn đề tiếp theo tui sẽ ráng dùng những patterns có sẵn của để tấn công webserver, web app, etc và bắt crawler của gmail đập vào những ip cùng subnet với nó (nhiều khả năng là những server khác của google).

6. thử test coi gmail có download 1 file nhiều lần hay ko? (có thể để tối ưu hoá thời gian ngồi chờ, nó thấy file nào nó đã down rồi thì ko down nữa). Nghĩa là nếu nó checksum nếu thấy cái file đó trong db rồi thì ko cần down nữa mà lấy file cũ attach lên ... khi đó có thể đoán xem nó checksum file bằng cách nào (md5, sha-1) để làm một file khác bị collision với file cũ và sẽ tồn tại 1 url mà gmal sẽ ko bao giờ thèm download ...
 

2a. làm sao khiến máy chủ GMail tải về một cái file có tên như thế?
 

4a. làm sao để xác định được GMail dùng "cái gì" để tải file về?

4b. làm sao để xác định cái đó có hỗ trợ Javascript hay không? nếu có thì có những chuyện gì để nói?

4c. ngoài ra nếu đã xác định được GMail dùng "cái gì" để tải file về, thì về nguyên tắc chúng ta nên làm gì tiếp theo để có thể tấn công vào máy chủ GMail?
 

b3. Scan & pattern matching có thể bị buf overflow hoặc dùng escape string để by pass nên chỉ có tác dụng một phần, không phải là giải pháp chắc chắn 100%

b4. Như jinx9 có nói, nếu yêu cầu gmail down về 1 file mà trúng server config tarpit rule thì sẽ tốn network resource để maintain connection. Hoặc là netcat /dev/random thì biết chừng nào mới down xong -> nếu để time limit thì sẽ hạn chế được long download. Trường hợp target server cố ý chỉ support http 1.0 nên gmail serrver không biết được lúc nào mới hết file.

Trường hợp target server support range (http 1.1) thì hạn chế size down để hạn chế disk usage cho server gmail.

Ý của mrro trong trường hợp 1 là để gmail scan port của chính gmail? hoặc các internal server của google?
 

b.3 Scan virus + pattern matching nội dung file sẽ attach để tránh các nội dung xấu

b.4 size limit & time limit cho việc download
 

Một phát hiện hết sức thú vị. Thú vị ở chỗ bao nhiêu người, bao nhiêu chuyên gia, bao nhiêu năm qua dòm vô TLS/SSL mà không thấy được lỗ hổng có vẻ như rất hiển nhiên mà các tác giả ở trên phát hiện. Có lẽ nguyên nhân nhiều người dòm nhưng không thấy là vì họ chỉ dòm TLS/SSL khi nó đứng một mình, mà không nhìn vào bức tranh lớn OSI, trong đó TLS/SSL chỉ là một layer. Chuyện gì sẽ xảy ra nếu TLS/SSL không hiểu rõ cơ chế hoạt động của các protocol bên trên nó, như HTTP, SMTP hay POP3? Nói cách khác, chuyện gì sẽ xảy ra nếu các protocol ở mức Application không hiểu rõ cơ chế vận hành của TLS/SSL để sử dụng cho đúng cách? Đó là lúc lỗ hổng xuất hiện.