前陣子“心臟出血”剛發生的時候讀了下源代碼，給出了自己覺得比較清楚的理解。 -------------------------穿越時空的分割線--------------------------- 參考：http://drops.wooyun.org/papers/1381 這個問題出現在openSSL處理TLS心跳的過程中，TLS心跳的流程是：A向B發送請求包，B收到包后讀取這個包的內容(data)，并返回一個包含有請求包內容的響應包。請求包的內容(data)中包含有包的類型(type)和數據長度等信息。 當B收到A的請求包后，并沒有的驗證A包的實際長度，而是簡單的把請求包data中說明的長度當作data的實際長度，于是當請求包中說明的長度與請求包數據實際長度不同時，問題就產生了。假設A構造一個請求包，它的實際內容長度只有1，而卻告訴B的它的長度是65535，那么B接受到這個包后就會把A的內容完全當作65535來處理，其實到這里，問題還并不嚴重，最嚴重的問題出在，心跳的響應包還需要附帶請求包的全部內容，這就需要程序做一次將請求包的數據從它所在的內存拷貝到響應包的內存里的操作，這下就出大問題了，當拷貝的時候，程序認為A包的內容長度是65535個字節，結果A包在內存里面實際只有1個字節，于是程序不僅拷貝出了A包的內容，還“傻傻”地將A包數據在內存中位置后額外的65534個字節拷貝進了響應包里，并將這個響應包發還給了A，于是A便輕易地獲得了B內存中這65534個字節的數據。想象一下，如果這65534個字節數據中包括一些敏感信息，那么后果將非常嚴重。而且A還可以簡單地通過連續的發送心跳包，獲取B機器內存中n個65534字節的數據，這個漏洞不愧是2014年“最佳漏洞”。 現實是殘酷的，據說的確已經有很多用戶的敏感信息通過這種方式泄漏了。作為一個應用如此廣泛和重要的開源庫，出現這種低級的問題實在是讓人不能理解，不禁又讓人聯想起了------陰謀！

轉載于:https://www.cnblogs.com/flyFreeZn/p/3860752.html

總結

以上是生活随笔為你收集整理的关于“心脏出血”漏洞(heartbleed)的理解的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。