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

• 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 :D 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ã.  

--> Đ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ó".  

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.  

 

À, 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 đó  

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. 

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

Ngắn gọn lại thì việc dùng AES256 hay RC4 là kết quả của bước bắt tay của giao thức TLS/SSL. -m 

nhanth87: đó là sự khác biệt giữa PRIVATE và PUBLIC 

thangdiablo wrote:

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.  

Đoạn này anh có nhầm không? Anh dùng IIS và Apache để generate ra CSR?  

Bộ K2 sẽ được CA sinh ra để ký vào public key mà chúng ta gửi cho CA nhằm mục đích xác thực cert của chúng ta là hợp lệ và duy nhất.  

Lúc này khi diễn ra một yêu cầu đăng nhập từ phía client (POST) Thì client và server sẽ dùng 1 khoá đối xứng K3 để mã hoá nội dung của thông tin and username + password. Lúc này giữa client và server cũng trao đổi luôn các thuật toán sẽ dùng với nhau. Tuy nhiên, nếu trao đổi cái khoá đối xứng này (dang clear text) trên đường truyền thì sẽ không an toàn. Do đó client sẽ dùng cái public key của phía server để encrypt cái K3 này. Sau khi trao đổi K3 thành công và an toàn rồi thì K3 này sẽ được dùng để mã hoá nội dung. PS: Phần màu vàng là phần tớ hoàn toàn không chắc chắn, do đó vẫn còn nhiều mù mờ. Mong các bạn chỉnh sửa thêm. Thanks  

No.     Time        Source                Destination           Protocol Info
      4 0.026146    172.16.128.198        172.16.32.99          TLSv1    Client Hello

Frame 4 (233 bytes on wire, 233 bytes captured)
Ethernet II, Src: Fortinet_09:00:00 (00:09:0f:09:00:00), Dst: Micro-St_6f:94:f2 (00:19:db:6f:94:f2)
Internet Protocol, Src: 172.16.128.198 (172.16.128.198), Dst: 172.16.32.99 (172.16.32.99)
Transmission Control Protocol, Src Port: 28460 (28460), Dst Port: https (443), Seq: 1, Ack: 1, Len: 167
Secure Socket Layer
    TLSv1 Record Layer: Handshake Protocol: Client Hello
        Content Type: Handshake (22)
        Version: TLS 1.0 (0x0301)
        Length: 162
        Handshake Protocol: Client Hello
            Handshake Type: Client Hello (1)
            Length: 158
            Version: TLS 1.0 (0x0301)
            Random
            Session ID Length: 0
            Cipher Suites Length: 68
            Cipher Suites (34 suites)
            Compression Methods Length: 1
            Compression Methods (1 method)
            Extensions Length: 49
            Extension: server_name
            Extension: elliptic_curves
            Extension: ec_point_formats
            Extension: SessionTicket TLS

No.     Time        Source                Destination           Protocol Info
      6 0.034700    172.16.32.99          172.16.128.198        TLSv1    Server Hello, 

Frame 6 (1514 bytes on wire, 1514 bytes captured)
Ethernet II, Src: Micro-St_6f:94:f2 (00:19:db:6f:94:f2), Dst: Cisco_18:ea:c9 (00:21:d8:18:ea:c9)
Internet Protocol, Src: 172.16.32.99 (172.16.32.99), Dst: 172.16.128.198 (172.16.128.198)
Transmission Control Protocol, Src Port: https (443), Dst Port: 28460 (28460), Seq: 1, Ack: 168, Len: 1448
Secure Socket Layer
    TLSv1 Record Layer: Handshake Protocol: Server Hello
        Content Type: Handshake (22)
        Version: TLS 1.0 (0x0301)
        Length: 74
        Handshake Protocol: Server Hello
            Handshake Type: Server Hello (2)
            Length: 70
            Version: TLS 1.0 (0x0301)
            Random
            Session ID Length: 32
            Session ID: ECC86D2FC674A9E5B28C2AA1AB535FB48969C0477DF7677D...
            Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
            Compression Method: null (0)

No.     Time        Source                Destination           Protocol Info
     13 7.432028    172.16.128.198        172.16.32.99          TLSv1    Certificate, Client Key Exchange, Certificate Verify, Change Cipher Spec, Encrypted Handshake Message

Frame 13 (1172 bytes on wire, 1172 bytes captured)
Ethernet II, Src: Fortinet_09:00:00 (00:09:0f:09:00:00), Dst: Micro-St_6f:94:f2 (00:19:db:6f:94:f2)
Internet Protocol, Src: 172.16.128.198 (172.16.128.198), Dst: 172.16.32.99 (172.16.32.99)
Transmission Control Protocol, Src Port: 28460 (28460), Dst Port: https (443), Seq: 168, Ack: 2561, Len: 1106
Secure Socket Layer
    TLSv1 Record Layer: Handshake Protocol: Multiple Handshake Messages
        Content Type: Handshake (22)
        Version: TLS 1.0 (0x0301)
        Length: 1042
        Handshake Protocol: Certificate
            Handshake Type: Certificate (11)
            Length: 770
            Certificates Length: 767
            Certificates (767 bytes)
                Certificate Length: 764
                Certificate (pkcs-9-at-emailAddress=xx,id-at-commonName=xx,id-at-organizationalUnitName=xx,id-at-organizationName=xx,id-at-localityName=HN,id-at-stateOrProvinceName=Ha Noi,id-at-countryName=VN)
        Handshake Protocol: Client Key Exchange
            Handshake Type: Client Key Exchange (16)
            Length: 130
        Handshake Protocol: Certificate Verify
            Handshake Type: Certificate Verify (15)
            Length: 130
    TLSv1 Record Layer: Change Cipher Spec Protocol: Change Cipher Spec
        Content Type: Change Cipher Spec (20)
        Version: TLS 1.0 (0x0301)
        Length: 1
        Change Cipher Spec Message
    TLSv1 Record Layer: Handshake Protocol: Encrypted Handshake Message
        Content Type: Handshake (22)
        Version: TLS 1.0 (0x0301)
        Length: 48
        Handshake Protocol: Encrypted Handshake Message

No.     Time        Source                Destination           Protocol Info
     14 7.441706    172.16.32.99          172.16.128.198        TLSv1    Change Cipher Spec, Encrypted Handshake Message

Frame 14 (125 bytes on wire, 125 bytes captured)
Ethernet II, Src: Micro-St_6f:94:f2 (00:19:db:6f:94:f2), Dst: Cisco_18:ea:c9 (00:21:d8:18:ea:c9)
Internet Protocol, Src: 172.16.32.99 (172.16.32.99), Dst: 172.16.128.198 (172.16.128.198)
Transmission Control Protocol, Src Port: https (443), Dst Port: 28460 (28460), Seq: 2561, Ack: 1274, Len: 59
Secure Socket Layer
    TLSv1 Record Layer: Change Cipher Spec Protocol: Change Cipher Spec
        Content Type: Change Cipher Spec (20)
        Version: TLS 1.0 (0x0301)
        Length: 1
        Change Cipher Spec Message
    TLSv1 Record Layer: Handshake Protocol: Encrypted Handshake Message
        Content Type: Handshake (22)
        Version: TLS 1.0 (0x0301)
        Length: 48
        Handshake Protocol: Encrypted Handshake Message

No.     Time        Source                Destination           Protocol Info
     26 12.645327   172.16.128.198        172.16.32.99          TLSv1    Client Hello

Frame 26 (265 bytes on wire, 265 bytes captured)
Ethernet II, Src: Fortinet_09:00:00 (00:09:0f:09:00:00), Dst: Micro-St_6f:94:f2 (00:19:db:6f:94:f2)
Internet Protocol, Src: 172.16.128.198 (172.16.128.198), Dst: 172.16.32.99 (172.16.32.99)
Transmission Control Protocol, Src Port: 28462 (28462), Dst Port: https (443), Seq: 1, Ack: 1, Len: 199
Secure Socket Layer
    TLSv1 Record Layer: Handshake Protocol: Client Hello
        Content Type: Handshake (22)
        Version: TLS 1.0 (0x0301)
        Length: 194
        Handshake Protocol: Client Hello
            Handshake Type: Client Hello (1)
            Length: 190
            Version: TLS 1.0 (0x0301)
            Random
            Session ID Length: 32
            Session ID: ECC86D2FC674A9E5B28C2AA1AB535FB48969C0477DF7677D...
            Cipher Suites Length: 68
            Cipher Suites (34 suites)
            Compression Methods Length: 1
            Compression Methods (1 method)
            Extensions Length: 49
            Extension: server_name
            Extension: elliptic_curves
            Extension: ec_point_formats
            Extension: SessionTicket TLS

No.     Time        Source                Destination           Protocol Info
     28 12.647093   172.16.32.99          172.16.128.198        TLSv1    Server Hello, Change Cipher Spec, Encrypted Handshake Message

Frame 28 (204 bytes on wire, 204 bytes captured)
Ethernet II, Src: Micro-St_6f:94:f2 (00:19:db:6f:94:f2), Dst: Cisco_18:ea:c9 (00:21:d8:18:ea:c9)
Internet Protocol, Src: 172.16.32.99 (172.16.32.99), Dst: 172.16.128.198 (172.16.128.198)
Transmission Control Protocol, Src Port: https (443), Dst Port: 28462 (28462), Seq: 1, Ack: 200, Len: 138
Secure Socket Layer
    TLSv1 Record Layer: Handshake Protocol: Server Hello
        Content Type: Handshake (22)
        Version: TLS 1.0 (0x0301)
        Length: 74
        Handshake Protocol: Server Hello
            Handshake Type: Server Hello (2)
            Length: 70
            Version: TLS 1.0 (0x0301)
            Random
            Session ID Length: 32
            Session ID: ECC86D2FC674A9E5B28C2AA1AB535FB48969C0477DF7677D...
            Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
            Compression Method: null (0)
    TLSv1 Record Layer: Change Cipher Spec Protocol: Change Cipher Spec
        Content Type: Change Cipher Spec (20)
        Version: TLS 1.0 (0x0301)
        Length: 1
        Change Cipher Spec Message
    TLSv1 Record Layer: Handshake Protocol: Encrypted Handshake Message
        Content Type: Handshake (22)
        Version: TLS 1.0 (0x0301)
        Length: 48
        Handshake Protocol: Encrypted Handshake Message

No.     Time        Source                Destination           Protocol Info
     30 12.677193   172.16.128.198        172.16.32.99          TLSv1    Change Cipher Spec, Encrypted Handshake Message, Application Data

Frame 30 (722 bytes on wire, 722 bytes captured)
Ethernet II, Src: Fortinet_09:00:00 (00:09:0f:09:00:00), Dst: Micro-St_6f:94:f2 (00:19:db:6f:94:f2)
Internet Protocol, Src: 172.16.128.198 (172.16.128.198), Dst: 172.16.32.99 (172.16.32.99)
Transmission Control Protocol, Src Port: 28462 (28462), Dst Port: https (443), Seq: 200, Ack: 139, Len: 656
Secure Socket Layer
    TLSv1 Record Layer: Change Cipher Spec Protocol: Change Cipher Spec
        Content Type: Change Cipher Spec (20)
        Version: TLS 1.0 (0x0301)
        Length: 1
        Change Cipher Spec Message
    TLSv1 Record Layer: Handshake Protocol: Encrypted Handshake Message
        Content Type: Handshake (22)
        Version: TLS 1.0 (0x0301)
        Length: 48
        Handshake Protocol: Encrypted Handshake Message
    TLSv1 Record Layer: Application Data Protocol: http
        Content Type: Application Data (23)
        Version: TLS 1.0 (0x0301)
        Length: 592
        Encrypted Application Data: 721F353AA5343A689F449FB76514F3F08A6E4E76275FFAB2...