• If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.
Xin chào ! Nếu đây là lần đầu tiên bạn đến với diễn đàn, xin vui lòng danh ra một phút bấm vào đây để đăng kí và tham gia thảo luận cùng VnPro.

Announcement

Collapse
No announcement yet.

hỏi về RSA

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    RE: hỏi về RSA

    cãi nhau mà làm gì, chẳng qua là do hiểu lầm thôi, bỏ qua đi

    bạn itmansaigon cứ tiếp tục mấy bài viết của bạn trong chủ đề này đi, tôi thấy mấy bài đó viết rất hay.

    trungnq76 là người đã sống và làm việc ở Mỹ nhiều năm, mới về chơi VN ít lâu nên có thể chưa quen với cách tranh luận như vậy, ở VN như vậy là thường mà anh ; - ), khi nào quay lại San Jose kiếm hộ tôi 1 con 2610XM nhé.

    Comment


    • #32
      Cám ơn ccie11285,

      Những lời nói của ccie11285 về chú trungnq76 làm tôi hơi ngạc nghiên đấy, thứ nhất là bên Mỹ tụi nó kỵ nhất là cái việc phân biệt tuổi tác, khi đi làm trong công ty ai mà giở cái thói khề khà ta đây là ông kẹ lớn tuổi để đi lòe những người nhỏ tuổi hơn là bị fired đấy, ai có thực lực thì người đó sẽ được trọng dụng, bất kể già trẻ gái trai. Nếu chú ở bên đấy làm mà chưa "thủng" được cái culture của người ta thì nguy lắm đấy

      Trở lại vấn đề tranh luận kỹ thuật một chút, tôi nghe chú nói nào là làm chung với những cao thủ siêu sao bên Mỹ, thế chú có học được những gì hay ho của tụi nó để cho bà con bên này biết không hay chỉ thích show off các Certificates của chú ra để lòe thiên hạ, thời buổi này vàng thật & vàng giả lẫn lộn nhiều lắm, chỉ khi đi đường xa mới biết được bạn hiền

      Hãy vào đây cùng tôi tranh luận tiếp CA đi xem nào, đừng có post mấy cái mục mua bán và quảng cáo nữa, không được hay lắm đâu
      Flux -> Flask -> SELinux (RHEL 4)
      Beating the 0-day vulrerability threat

      Comment


      • #33
        RE: hỏi về RSA

        Làm kỹ thuật đúng là đôi khi phải tranh luận cho đến khi thỏa mãn thì thôi, nhưng măng chó chủi mèo thi không hay chút nào.

        Tôi đồng ý với Crazy, nghĩa là ACB có quyền dùng CA nào để cấp cert. Làm sao có chuyện giả mạo cert của ACB khi khách hàng của ACB đc thông báo là website https://online.acb.com.vn của ACB dùng cert của VASC?

        Vả lại không có cert nào là giả cả chỉ có vấn đề là khách hàng có tin CA cấp ra cert đó hay không. Theo toi, tại VN khách hàng họ biết rõ VASC hơn là Verisign.

        Thừ hai, tôi cũng đồng ý với Crazy, là nếu Cert của VASC là không đáng tin thì browser đã không cho chúng ta import chain của VASC, và cũng không cho remove của Verisign.

        Thế ITMan có bao giờ trả lời cho câu hỏi "tại sao trên thế giới hiện có nhiều CA mà không là duy nhất?" khi nào bạn trả lời đúng câu hỏi này thì bạn sẽ hiểu được vấn đề ngay thôi.

        "Con người khi thấy người ta sai mà không cố vạch ra là bất nhân" vậy nếu anh muốn là "hữu nhân" thì gạch đầu dòng các điểm sai của ACB để tiện đường tranh luận.

        Comment


        • #34
          RE: hỏi về RSA

          Xin chào acb,

          Chú cứ nhầm lẫn mãi cái entity để chứng thực cho cái certificate nữa rồi, nó ở đây là web browser chứ không phải là khách hàng, mà nếu khách hàng nhỉn vào thì bao nhiêu phần trăm biết được VASC là chú nào? chú muốn khách hàng dùng ebanking thì phải học IT ả, học IT chăng nữa cũng thì bao nhiêu người trong số đó biết VASC, Verisign là cái gì? cái quan trọng là khi chú làm Internet banking để cho khách hàng điền vào các thông tin nhạy cảm như username, PIN, credit card # thì chú phải tuân theo các chuẩn chung, chứ không phải vì tự ái cho cái gọi là người VN thì phải dùng hàng VN như chú và một số người trong đây đã nghĩ, thực ra ngay từ đầu tôi đã nói với chú là ACB thực hiện Internet banking nửa vời, nếu trả tiền cho một CA mà không có một cái ENTITY nào trust hết thì tốt hơn hết là tự mình sign cho mình như VCB đang làm còn hay hơn đấy, tôi xin biếu chú vài tài liệu để chú tham khảo, sau khi chú đọc xong thì tôi xin hầu chuyện chú tiếp

          1/ http://www.awprofessional.com/articl...32280&seqNum=5
          2/ http://www.whichssl.com
          3/ http://www.us.kpmg.com/RutUS_prod/Do...12/DC80502.pdf

          P.S. Trong tài liệu của KPMG chú nên đọc hết từ trên xuống cho kỹ và tập trung vào phần "Relying Party Control Considerations" xem họ nói gì
          Flux -> Flask -> SELinux (RHEL 4)
          Beating the 0-day vulrerability threat

          Comment


          • #35
            RE: hỏi về RSA

            Dựa vào những gì nói trong document của KPMG mà tôi đã cho chú đọc trước có nói rằng khi site's certificate không được các Trusted CA ký thì integrity và confidentiality từ máy bạn đến đối tác (website server) vẫn được bảo đảm nhưng không bảo đảm được tính xác thực (authentication) của đối tác đó, nếu chú vẫn chưa hiểu được document đó thì tôi sẽ minh họa ra đây

            Khi khách hàng truy cập vào https://online.acb.com.vn/index.jsp hiện lên warning Security Alert thì chú khuyến cáo khách hàng chọn Yes hay No, dĩ nhiên là Yes rồi vì chú muốn khách hàng đăng nhập vào hệ thống của mình phải không? (Mà điều này lả tối kỵ đối với các giao dịch Internet banking khi thấy Security Alert mà vẫn cố tình chọn Yes để tiến hành giao dịch, khi đó hiện tượng giả mạo có thể xảy ra)

            1/ Trường hợp giả CA của VASC
            Tôi sẽ dựng lên một web site có nội dung y hệt như web site đăng nhập của ACB, sau đó dùng O/S MS Windows 2000 chẳng hạn install cho nó có chức năng CA, khi cài các thông số cho CA này tôi set như sau

            E = camaster@vasc.com.vn
            CN = VASC Secure Server CA - Class 3
            OU = VASC CA
            O = VASC
            L = Hanoi
            S = Hanoi
            C = VN

            Những bước này hoàn toàn làm được dễ dàng phải không. Sau khi có một CA có các thông số y hệt như VASC, tôi mới gán cho web site đăng nhập giả ở trên một địa chỉ IP của tôi là 203.162.1.10 chẳng hạn, sau đó mới dùng CA giả đó để sign lên cái site's certificate đó với các thông số sau

            CN = online.acb.com.vn
            O = Asia Commercial Bank
            S = Ho Chi Minh
            L = Quan 1
            C = VN

            Giả sử DNS server của ISP, hay công ty mà các khách hàng của ACB đang dùng bị lỗi và tôi có thể poison được DNS đó để cho các A record của online.acb.com.vn sẽ chỉ vào 203.162.1.10 thay vì 210.245.41.213, khi đó tôi sẽ tha hồ ngồi đó mà nhận các sentitive information mà khách hàng của ACB đang gởi cho tôi thay vì cho ACB, vì warning Security Alert hoàn toàn giống như của ACB khi chưa bị poison DNS.

            Nhưng nếu tôi sử dụng các site's certificates do các trusted CA của Verisign hay Thawte ký và cảnh báo khách hàng không tiến hành giao dịch khi thấy bất cứ một Security Alert nào hiện ra, thì nếu trường hợp DNS của khách hàng có bị poison đi chăng nữa, khi đó cửa sổ warning Security Alert sẽ hiện ra cho biết là site's certificate này không trust được (vì có được Verisign hay Thawte chứng thực và ký đâu mà trust) khi đó khách hàng sẽ không tiến hành giao dịch nữa

            Việc dùng các trusted CA có ý nghĩa quan trọng như thế đấy chú ạ

            2/ Trường hợp giả CA cho các site tự build lấy CA ví dụ như VCB

            Cũng tương tự như trên, chỉ cần set các thông số khi cài đặt CA giống như VCB là được

            Sau khi đọc xong phần này, xin chú cho biết ý kiến đi nhé, đã lỡ "mắng" nhau rồi thì phải làm cho ra lẽ đấy
            Flux -> Flask -> SELinux (RHEL 4)
            Beating the 0-day vulrerability threat

            Comment


            • #36
              RE: hỏi về RSA

              Hi ITManSG,

              Từ khi tham gia diễn đàn này đến giờ mới thấy có cuộc tranh luận hấp dẫn như thế này, vậy thì nó mới thu hút và học hỏi được nhiều phải không??? Nói tóm lại của vấn đề này là khi MS đưa ra IE đã Import Certificates của Verisign, Thawte,... vào rồi nên không thể giả được phải không, còn VASC không có nên khi khách hàng vào sẽ bị Sercurity Alert mà theo chú "là tối kỵ đối với các giao dịch Internet banking khi thấy Security Alert mà vẫn cố tình chọn Yes để tiến hành giao dịch, khi đó hiện tượng giả mạo có thể xảy ra" phải không??? Vậy thì để tôi gửi mail cho VASC yêu cầu Bill Gate Import luôn của họ vào trước đi, để khách hàng của họ khỏi lo sợ khi giao dịch, RIGHT??? Bây giờ chú chỉ có 2 cách trả lời với tôi thôi là YES or NO, nếu chú trả lời là YES thì những ai tham gia đề tài này không tranh luận gì nữa đâu (vì lúc đó chú sẽ thấy Viresign, Thawte,... hay VASC gì đó đều như nhau cả, chẳng qua là do nó được Bill Gate "ưu ái" Import vào trước hay sau thôi), còn nếu chú trả lời là NO thì BÓ TAY, lúc đó tôi đảm bảo với chú rằng, chắc chú là người thích chữ VERISIGN hơi chữ VASC hoặc chú là người giới thiệu VERISIGN vào ACB nhưng họ không mua nên đăm ra chê ACB làm việc nữa vời (việc này thì anh A BỜ CỜ gì đó ơi, kiểm tra xem có phải vậy không nhé???).

              Nhưng anh bạn trẻ àh, nhưng cuộc đời không đơn giản như những gì anh bạn đọc đâu, tôi biết anh là người tốt vì người tốt nên mới nói "Con người khi thấy người ta sai mà không cố vạch ra là bất nhân", và tôi cũng không muốn làm người xấu nên cũng phải nói ra những cái chú đang nhầm lẩn hay chỉ vì chú thích chữ Verisign nên đâm ra cố chấp :

              Thứ nhất : Vì các CA được MS import sẵn nên chú nghỉ là khi khách hàng vào website nào không có trong danh sách đó sẽ không an toàn vì được thông báo Security Alert mà không được press YES huhuhuuhuh... vậy là toi, nói thế là để khẳng định rằng chú chỉ mới đọc chứ chưa làm thật bao giờ (chỉ đọc và cài đặt thì là chưa hiểu hết đâu chú em àh), vì chú cứ nghỉ rằng khách hàng giao dịch lần đầu sẽ bị Security Alert, nhưng chú đâu có hiểu 1 quy trình VASC cấp cert. cho khách hàng như thế nào??? và hướng dẫn họ phải làm những gì trước khi giao dịch... Khi đó anh muốn hiện lên Security Alert cũng không thấy. Nếu chú muốn biết họ làm như thế nào thì mở o ACB 1 account và xin giao dịch trực tuyến thử đi rồi chú sẽ biết ngay thôi mà, tôi cũng từng thắc mắc như thế và cũng muốn xem họ đang làm cái quái gì, có lủng chổ nào không để còn hack chứ, và tôi đã làm 1 cái account ở ACB và xin chữ ký ở VASC, khi gặp VASC họ nói thế nào không "tất cả các giao dịch của khách hàng nếu bị mất tiền thì họ sẽ đền đủ không thiếu 1 xu", còn cái cert. họ cấp cho mình thì có nhiều cách để mình nhận và hướng dẫn mình import vào... rồi giao dịch, đảm bảo an toàn cho khách hàng. Nói chung là muốn ăn thì phải lăn vào bếp anh bạn trẻ àh, nếu không có cơ hội làm mà muốn biết hệ thống thất họ sẽ làm như thế nào thì cũng phải làm 1 vòng để xem thực tế là như thế nào, để biết có hack họ được không vì theo tôi biết ở ACB có treo giải đó, nếu anh chỉ ra được họ sẽ lấy lương và thưởng của bộ phận đó cho anh đấy.

              Thứ hai : Vì cái nhìn của anh bạn trẻ quá ư là cố chấp nên không nhìn thấy những cái hay của hệ thống khác mà học hỏi cách ho làm, tôi cũng thông cảm với chú em vì ai không từng trải qua thời lý thuyết.

              Thứ ba : Lý thuyết là chú có thể hack DNS,... tất cả, giả mạo tất cả CA mà đã mơ thì mơ cho chót, không mơ là giả mạo được Verisign rồi hack vào máy của khách hàng xóa hết mấy cái của Verisign thật đi rồi import Verisign giả vào, mà khách hàng của Verisign thì nhiều lắm và giao dịch toàn tiền Mỹ không đấy, dù gì tiền đô cũng ngon hơn tiền việt mà, hơi đâu đi giả mạo của VASC.

              Oh, nói sao nhiều thế nhỉ!!!

              Ah! Còn anh A CỜ BỜ gì đó ơi, nói anh đừng tự ái nhé, anh nói ngân hàng nhiếu tiền, vậy thì nói sếp của anh sao không mua Verisign mà dùng lại đi dùng VÁC vít gì để người ta chê là Internet-Banking ở Việt Nam là việc nữa vời. Tôi mà như anh thì từ chức quách cho rồi...
              Crazy ®

              Comment


              • #37
                RE: hỏi về RSA

                Xin chào Crazy,

                Không ngờ đến giờ này bác mới nói nhiều đến như vậy, nhưng tôi vẫn còn đủ sức để tranh luận MARATHON đến cùng với bác về vấn đề này, không biết bác có đọc kỹ những document (KPMG) & minh họa mà tôi đã đưa ra không, cái bản chất của TRUSTED CA chính là nó bảo đảm là dù trong tình huống nào đi nữa (DNS có bị poison hay không) thì vẫn bảo đảm cho khách hàng được an toàn, mà chuyện poison DNS này làm không mấy khó khăn đâu bác à, trên Internet chỉ cần công ty nào sơ sẩy enable DNS server của họ cho phép ZONE TRANSFER là có thể poison được ngay đấy (không cần đợi cho nó bị lỗi đâu) và trong mạng LAN thì việc poison DNS còn dễ dàng hơn nữa (dể như ăn cơm sườn)

                Nhưng khi tôi dùng các TRUSTED CA (tôi đã nói cái từ này rất nhiều lần rồi) để sign cái site's certificate của tôi thì không có tình huống nào có thể giả mạo được (đó chính là cái tính năng AUTHENTICATION mà TRUSTED CA cung cấp cho khách hàng). Khi có hai khả năng như vậy để chọn thì bác sẽ chọn cái nào? đừng có là lại đi chọn cái risky nhé

                Và thêm nữa, không phải chỉ có MS mới built-in cái ROOT TRUSTED VERISIGN CERTIFICATES mà hầu như 99% các loại web browser đều có, nên nó mới được sếp vào loại HIGH-ASSURANCE SSL CERTIFICATE và mắc nhất trong tất cả các loại TRUSTED CA hiện nay

                Tôi cũng dám đưa ra kết luận là: ai đang dùng cái VASC để ký cho cái site's certificate dùng trong giao dịch Internet Banking khi sử dụng SSL (https) là hoàn toàn TẦM BẬY và không hiểu biết (vì VASC CA không bảo đảm được tính AUTHENTICATION cho khách hàng)

                Và chính vì vậy mà tôi đang cố gắng để chỉ ra cái TẦM BẬY đó để hoàn thiện hơn cho cái Internet Banking ở nước nhà

                Rất vui khi được cùng bác tranh luận nữa nhé (phải dùng lý lẽ kỹ thuật đấy chứ đứng có "mắng" nhau suông)
                Flux -> Flask -> SELinux (RHEL 4)
                Beating the 0-day vulrerability threat

                Comment


                • #38
                  RE: hỏi về RSA

                  Hehehe,
                  Cho tui chạy theo với, các chú chạy nhanh quá.

                  ITMan ui, chú có thể giả lập như những điều chú nói, nhưng nếu khách hàng đã import chain của VASC xuống thì sao? Chắc có lẽ chú sẽ bị CA (Công an) cho vào nhà đá!

                  Tại sao bọn Verisign... làm root được còn VASC không? Chú em trả lời đi?

                  Một lần nữa tui khuyên chú ITMan dùng lời lẽ lịch sự một tí. Tranh luận giữa những người có học thức chứ không phải hàng tôm hàng cá mà dùng từ ngữ nặng nề quá.

                  Tôi không hiểu tại sao chú cố chấp quá. Nếu kiến thức của chú cộng với sửa đổi tính cách 1 tí chắc nước VN sẽ là rồng bay thực sự đó. Tôi chỉ muốn nhắc nhớ cho chú vài điều thui.

                  Nhân đây tôi cũng nói cho chú biết, Trung Quốc có hàng chục CA nhiều hơn cả Mỹ, vậy không lẽ các CA của TQ là dzom hết sao?

                  Comment


                  • #39
                    RE: hỏi về RSA

                    Xin chào các bác,

                    Bất kỳ ai cũng có thể set một cái CA và sign cho người khác hay chính mình, nhưng cái vấn đề mấu chốt ở đây là những cái TRUSTED CA thì mọi ENTITY (Web Browser) đều tin (TRUSTED) ngoài ra mọi cái CA khác đều có giá trị như nhau là ENTITY không có tin (NON-TRUSTED)

                    Tại sao các bác không tự đặt ra câu hỏi: vậy thì sao mình lại phải bỏ tiền ra để cho một thằng NON-TRUSTED CA khác ký cho mình làm gì? đã vậy tại sao mình không ký luôn cho mình được nhỉ? (như VCB đang làm) và vì chúng ta đều dùng hàng NON-TRUSTED với nhau cả nên bây giờ mới phải ép các ENTITIES cho nó phải TRUST mình, nếu để cái root non-trusted certificate lên website của mình cho khách hàng download xuống import thì cũng không xong rồi vì web site của mình cũng có thể bị giả mạo kia mà, còn nếu copy ra đĩa mềm rồi giao cho khách hàng về import vào PC của khách hàng ư? ai hướng dẫn, máy dùng Unix, Linux, Macitosh... khi import vào thì phải như thế nào? Khách hàng đi đâu chơi mà muốn dùng một cái PC khác để logon vào banking website ACB hay VCB phải kè kè cái đĩa mềm chứa non-trusted root certificate đó theo import vào để không nhìn thấy warning Security Alert thì mới chắc cú à?... những câu hỏi như vậy sao các bác không tự mình nghĩ ra được mà phải để tôi nói ra ?

                    Tôi đề nghị các bác cứ đọc kỹ lại những gì tôi đã nói và đã cung cấp vì tôi thấy rằng các bác cần có thêm thời gian để hiểu được vấn đề, hẹn 3 ngày sau tranh luận tiếp, trong thời gian đó các bác cứ dẫn chứng bằng facts hay documents ra đây đi, các bác không thể cứ mãi nói chuyện suông và thiếu cơ sở mãi như vậy được

                    Đến thứ Bảy tới tôi lại xin hầu chuyện các bác
                    Flux -> Flask -> SELinux (RHEL 4)
                    Beating the 0-day vulrerability threat

                    Comment


                    • #40
                      RE: hỏi về RSA

                      Chú ITMan cứ nghĩ ngơi đi du lich Vũng tàu cho thoải mái. Để tránh lạc chủ đề của maithanh232 tui mở thread mới để tranh luận cho rõ ràng.Xin nhấn vào đây

                      Comment


                      • #41
                        RE: hỏi về RSA

                        Tôi nghĩ không có gì là lạc đề hết, nó nằm trong phần ứng dụng của RSA dùng cho SSL (https) và CA tại sao chú lại nghĩ nó là lạc đề?? acb à với cách nói chuyện của chú từ khi chú tham gia cái thread này cho đến giờ thì mỗi lần để tiếp tục nói chuyện với chú thì tôi lại phải giải thích ra những câu nói ngây ngô trước đó của chú đấy chú có biết không?

                        Để cho mọi người nhìn vào cái thread này xem quan điểm từ đầu đến cuối của mỗi người thay đổi theo từng giai đoạn sẽ như thế nào

                        Các bác cứ cố gắng sưu tầm tư liệu hay dẫn chứng cụ thể từ đây cho đến thứ Bảy nhé
                        Flux -> Flask -> SELinux (RHEL 4)
                        Beating the 0-day vulrerability threat

                        Comment


                        • #42
                          RE: hỏi về RSA

                          Xin chào các bác,

                          Tôi rất thất vọng vì không được thấy bất cứ một tư liệu hay dẫn chứng cụ thể nào từ phía các bác cả

                          Nhân đây tôi cũng tổng kết lại những nhận định của mình về vấn đề này

                          TRUSTED CERTIFICATE bảo đảm được đầy đủ ba yếu tố cho một site đó là: CONFIDENTIALITY, INTEGRITY, và AUTHENTICATION

                          CONFIDENTIALITY: Không ai có thể đọc được nội dung giao dịch giữa site và web browser
                          INTEGRITY: Bảo đảm được tính toàn vẹn của data, không ai có thể sửa đổi lại data
                          AUTHENTICATION: Bảo đảm được tính xác thực của web site, không ai có thể giả mạo được

                          Với những thông tin tôi đã phân tích và dẫn chứng ở các phần trên, khi sử dụng các loại TRUSTED CA có mức high-assurance ssl certificate (được thể hiện bằng con số 99% tất cả các loại web browser đều built-in sẵn ROOT TRUSTED CERTIFICATE) thì tính xác thực (AUTHENTICATION) cho các site luôn luôn được bảo đảm trong bất kỳ trường hợp nào

                          Do VASC CA là loại NON-TRUSTED CERTIFICATE do đó những ai đang dùng nó để ký và chứng thực cho cái site's certificate dùng trong giao dịch Internet Banking khi sử dụng SSL (https) là hoàn toàn TẦM BẬY và không hiểu biết vì VASC CA không bảo đảm được tính AUTHENTICATION cho site của khách hàng (trường hợp của ACB)

                          Đối với các site dùng trong giao dịch Internet Banking tự mình ký và chứng thực cho mình (ngoại trừ chính các TRUSTED CA) thì cũng không bảo đảm được tính xác thực AUTHENTICATION cho site của mình (trường hợp của Vietcombank)

                          Một quốc gia hay một tổ chức doanh nghiệp vẫn có thể xây dựng lên một CA riêng để chứng thực và sign cho các hoạt động dịch vụ của mình ví dụ như chứng minh thư điện tử, thẻ an ninh cho nhân viên... tùy theo đặc điểm và tính chất của mỗi thực thể (ENTITY) là gì mà ta có thể lựa chọn kiểu CA áp dụng cho nó, nhưng đối với ENTITY là web browser và kiểu giao dịch là Internet banking thì việc sử dụng các high-assurance ssl certificate ví dụ như Verisign là biện pháp hoàn toàn ĐÚNG ĐẮN và hữu hiệu để bảo đảm được đầy đủ cả 3 yếu tố CONFIDENTIALITY, INTEGRITY, và AUTHENTICATION

                          Khi xây dựng một giải pháp an toàn cho Internet Banking chúng ta nên tính đến mọi trường hợp xấu nhất có thể xảy ra, không nên làm việc một cách tùy tiện như vậy sẽ tự mình làm mất uy tín cho mình

                          To Crazy:
                          Kinh nghiệm có nhiều cách để đạt được: Có thể do người khác truyền lại (thông qua tài liệu, số liệu) và tự mình rút ra được bài học từ những người đi tiên phong. Kinh nghiệm cũng có thể tự mình trải qua rồi mới rút ra được, nhưng nếu biết cách để có thể rút ra được kinh nghiệm cho mình nhờ những gì mà những người đi tiên phong truyền đạt lại thì mới hiệu quả hơn chứ phải không bác Crazy?

                          To acb:
                          Khi tranh luận thì phải đưa ra dẫn chứng và số liệu cụ thể chứ đừng nói bâng quơ như vậy, mọi người cười cho đấy

                          Các bác Crazy và acb hãy vảo đây tranh luận tiếp tục đi chứ, khi đã bắt tay làm một việc gì thì chúng ta hãy cố gắng làm cho ra "ngô ra khoai" chứ đừng chỉ có nói đùa và nói suông nhé các bác
                          Flux -> Flask -> SELinux (RHEL 4)
                          Beating the 0-day vulrerability threat

                          Comment


                          • #43
                            RE: hỏi về RSA

                            Tôi xin phép góp một số ý kiến cá nhân:

                            Nếu đã không dùng Trusted Root Certificates (Verisign, Entrust, Baltimore, Thawte...) được Import sẵn vào Web browser thì đều có nguy cơ rủi ro, dù cho dùng VASC hay một CA do mình tự ký thì rủi ro đều như nhau.

                            Nhưng trên thực tế áp dụng tại ACB và VCB cho thấy, nguy cơ rủi ro của VCB cao hơn của ACB (VCB dùng CA tự ký, ACB dùng VASC) bởi lẽ ACB có quy trình cấp certificate cho KH out-of-band để khách hàng tự import còn VCB thì cấp in-band luôn. Khi vào mục Banking online của VCB thì hiện ra một cửa sổ thông báo là "Download CA" về, tức là in-band luôn trong phiên làm việc đó, như vậy nếu Web site của VCB bị giả mạo thì các certificate được download về cũng là đồ giả. Còn trong trường hợp của ACB thì do certificate được cấp out-of-band nên không thể giả được, tuy nhiên khách hàng phải giao dịch trên máy mà họ đã import certificate đó, nếu họ ngồi ở một máy khác chưa được import certificate đó thì vẫn chịu rủi ro. Hiện nay RSA có một giải pháp là embed luôn cái certificate vào Token card (cái này dùng cổng USB), cũng hơi bất tiện là đi đâu cũng phải đem theo cái Token này, khi cần giao dịch thì cắm vào cổng USB và nó tự import certificate cho mình.

                            Nếu VCB cũng thực hiện việc cấp certficate cho khách hàng out-of-band để khách hàng tự import thì lúc đó mức độ an toàn của VCB và ACB là hoàn toàn như nhau, và như vậy thì không cần phải mua subscription của VASC đỡ tốn tiền. Tất nhiên là không ngon bằng mấy cái default trusted CA rồi vì dùng mấy cái hàng hiệu kia thì có thể giao dịch an toàn mọi nơi mọi lúc mà không cần mất thao tác import certificate (thao tác này nhiều khi cũng bị coi là phức tạp đối với mấy ông khách hàng không rành về IT).

                            Bạn ITmansaigon có thể giải thích rõ hơn về phần "các Trusted CA có thể đảm bảo rằng dù cho trong tình huống nào đi nữa, như DNS hack, thì khách hàng vẫn được an toàn" được không? Đây là điểm rất thú vị

                            Comment


                            • #44
                              RE: hỏi về RSA

                              Còn một vấn đề tôi vẫn chưa biết là khi có lừa đảo phishing xảy ra thì người chịu trách nhiệm là khách hàng hay là ngân hàng?

                              Nếu người chịu trách nhiệm là tự khách hàng (ai bảo ông chọn ngân hàng của tui mà mở tài khoản, bây giờ mất tiền ráng chịu) thì không nói làm gì rồi. Nhưng nếu người phải chịu trách nhiệm là ngân hàng thì cũng có thể nên sử dụng CA của VASC và trong hợp đồng ký với VASC sẽ đưa ra điều khoản là "VASC sẽ chịu hoàn toàn trách nhiệm và đền bù mọi thiệt hại cho khách hàng của ngân hàng XYZ nếu lừa đảo phishing xảy ra khi sử dụng dịch vụ banking online".

                              Các bác thấy thế nào?

                              Comment


                              • #45
                                RE: hỏi về RSA

                                Xin chào ccie11285,

                                Trong phần minh họa ở trên tôi đã đưa ra hai mối nguy hiểm khi dùng các NON-TRUSTED CERTIFICATE cho website.

                                Nhưng nếu sử dụng các site's certificates do các trusted CA của Verisign hay Thawte ký và cảnh báo khách hàng không tiến hành giao dịch khi thấy bất cứ một Security Alert nào hiện ra, thì nếu trường hợp DNS của khách hàng có bị poison đi chăng nữa (redirect tới một web site giả khác), khi đó cửa sổ warning Security Alert sẽ hiện ra cho biết là site's certificate này không trust được (vì không được Verisign hay Thawte chứng thực và ký, các certificate này được các CA ký bằng PRIVATE key của mình) khi đó khách hàng sẽ không tiến hành giao dịch nữa, và nguyên tắc này đã được xem là cơ bản để chống nạn "fishing" trong việc giả mạo web site.

                                Mọi ngân hàng trên thế giới khi tiến hành giao dịch Internet banking sử dụng ssl https đều dùng các high-assurance ssl certificate để tránh trường hợp cho khách hàng bị lừa vào các website giả mạo

                                Khi dùng VASC CA để chứng thực cho cái website của mình thì cái bậy của người thuê bao là không biết được VASC CA không bảo đảm được tính AUTHENTICATION cho site của mình mà vẫn chấp nhận, và cái bậy của VASC là không bảo đảm được tính AUTHENTICATION cho site của khách hàng thuê bao mà vẫn đứng ra làm CA. Hiện nay ở VN chưa có luật thương mại điện tử rõ ràng thì khi khách hàng bị mất tiền thì ai là người là người bị thiệt thì chắc các bạn cũng tự mình suy luận ra được chứ

                                Có một điều thú vị mà tôi vừa phát hiện ra là VDC đã hợp tác với TrustAsia để chứng thực cho các website ở VN, do TrustAsia là một phân cấp của root Verisign nên khi đăng ký tại TrustAsia thì ta cũng được thừa hưởng high-assurance ssl certificate y như khi sử sụng root Verisign certificate



                                Như vậy ACB đã sai lầm khi không thông qua VDC CA để có được TRUSTED CERTIFICATE của Verisign, thật là một sai lầm tệ hại & đáng trách cho ACB
                                Flux -> Flask -> SELinux (RHEL 4)
                                Beating the 0-day vulrerability threat

                                Comment

                                Working...
                                X