Anywhere you go, let me go too

關於部落格
對人海闊天空,做事仔細周密
----------------------
因為改了平台後...覺得不是很好用....所以有另外......(評估中)
http://blog.xuite.net/king119wang/myskills
  • 32543

    累積人氣

  • 2

    今日人氣

    0

    訂閱人氣

Mainframe Connection secure FTP TEST

這陣子協助幫忙架Open系統端的FTPS server,
讓MainFrame可以去試這一段的連線,
昨天在測試時發現有中斷的問題,
由FTPS Server看到一個很怪的狀況,
怎麼會都沒有登入user 帳號密碼???
原本還在思考是因為MainFrame加密方式,FTPS Server不接受.....
後來決定重頭開始找原因。

於是就做列事情慢慢解決問題:
1.在open端架起wireshark工具(抓網路封包)
    結果因為後面MainFrame開始送加密訊息,陷入焦著,後來許襄理就給了我個網址去學怎麼看TLS的封包。
 被這麼一說還以為這段加密動作通訊是在TCP/IP層做的(後面再解釋)....但在看封包的過程中,發現只看Open端和MainFrame端連線封包,實在很難找出原因。
 似乎要有一個對照組來比較才能找出問題,於是做了第二步。
2.抓取SecureFTP工具當Client,去試各種連線狀況,把封包抓下來
3.用之前寫的程式去測連線(Load certificate和沒有Load certificate的狀況),再抓package
4.去比較成功傳輸和不成功傳輸package傳送的情形
 結果找出了差異點:有圖有真像,下面分別來看一下失敗和成功的封包傳傳送過程。
 *因機密,所以把IP塗了,註明一下,192.168.11.* 是 FTPS Server 而 10.* 是Client 
   Step1:當通訊層成功進入ap層時,FTPS Server都會回訊息跟Client一個回應(這時還沒走SSL)
 
 
[成功的情形]
    Step 2:會由Client發動跟主機說我要用什麼加密方式
 

 Step 3:Server端會回他OK,咱們來走SSL吧 !
   
       之後就可以正常的做傳輸了。

[失敗的情形]
 Step2:Client端沒跟主機說它要用什麼方式加密,就直接把加密電文往上送,所以後續就跟著失敗。
 
 (但這也可能是因為FTPS Server並沒有強制一定要走加密,所以Client沒有告知,會造成Server不知如何是好,如果FTPS Server強制只能走SSL加密,是否這樣的傳輸將會成功???這值得再進一步研究。)
 許襄理發現是因為Port990之前曾有一段時間被訂成另一個Service的使用port,所以MainFrame會認為不用跟我說他要走什麼(SSL...),於是由open端改設走991,解決了SSL通訊層問題。
--------------------------------------------
 這點讓我更釐清SSL TCP傳輸,真正在做通訊層的handshaking動作,僅止於IP Layer層,只要在FTP
Server Log有看到連線記錄,其實已不是IP Layer問題,而是Layer 7 AP層的事。因為FTPPPP是屬於Layer 7的事,致於要做SSL其實已是在AP Layer之上了。
    其實IP層應該不太可能做加密啦!如果做不就所有通訊設備都要實作這一段,從MAC層就要有處理加密資料的能力.......(茲事體大)
 
 所以由封包可以看到FTPS Server有跟Client回"歡迎光臨"(類似在做這種事^^),這些都還是明碼,之後Client端會跟Server說,我要跟你走SSL,then Server說OK,我們開始走SSL Connection吧! 之後才是加密的。
--------------------------------------------
補一下wiki關於TLS Negotiation的順序(蠻有趣的)
引用自:http://en.wikipedia.org/wiki/Transport_Layer_Security
 
Negotiation phase
 
  • A client sends a ClientHello message specifying the highest TLS protocol version it supports, a random number, a list of suggested cipher suites and compression methods.
  • The server responds with a ServerHello message, containing the chosen protocol version, a random number, cipher suite, and compression method from the choices offered by the client. The server may also send a session id as part of the message to perform a resumed handshake.
  • The server sends its Certificate message (depending on the selected cipher suite, this may be omitted by the server).[13]
  • The server requests a certificate from the client, so that the connection can be mutually authenticated, using a CertificateRequest message.
  • The server sends a ServerHelloDone message, indicating it is done with handshake negotiation.
  • The client responds with a Certificate message, which contains the client's certificate.
  • The client sends a ClientKeyExchange message, which may contain a PreMasterSecret, public key, or nothing. (Again, this depends on the selected cipher.) This PreMasterSecret is encrypted using the public key of the server certificate.
  • The client sends a CertificateVerify message, which is a signature over the previous handshake messages using the client's certificate's private key. This signature can be verified by using the client's certificate's public key. This lets the server know that the client has access to the private key of the certificate and thus owns the certificate.
  • The client and server then use the random numbers and PreMasterSecret to compute a common secret, called the "master secret". All other key data for this connection is derived from this master secret (and the client- and server-generated random values), which is passed through a carefully designed "pseudorandom function".





  
相簿設定
標籤設定
相簿狀態