2014年2月22日，在這個“這么二”的日子里，蘋果公司推送了 iOS 7.0.6（版本號11B651）修復(fù)了 SSL 連接驗(yàn)證的一個 bug。官方網(wǎng)頁在這里：http://support.apple.com/kb/HT6147，網(wǎng)頁中如下描述：

Impact: An attacker with a privileged network position may capture or modify data in sessions protected by SSL/TLS

Description: Secure Transport failed to validate the authenticity of the connection. This issue was addressed by restoring missing validation steps.

也就是說，這個bug會引起中間人攻擊，bug的描述中說，這個問題是因?yàn)閙iss了對連接認(rèn)證的合法性檢查的步驟。

這里多說一句，一旦網(wǎng)上發(fā)生任何的和SSL/TSL相關(guān)的bug或安全問題，不管是做為用戶，還是做為程序員的你，你一定要高度重視起來。因?yàn)檫@個網(wǎng)絡(luò)通信的加密協(xié)議被廣泛的應(yīng)用在很多很多最最需要安全的地方，如果SSL/TSL有問題的話，意味著這個世界的計算機(jī)安全體系的崩潰。

Bug的代碼原因

Adam Langley的《Apple’s SSL/TLS bug 》的博文暴出了這個bug的細(xì)節(jié)。（在蘋果的開源網(wǎng)站上，通過查看蘋果的和SSL/TLS有關(guān)的代碼變更，我們可以在文件sslKeyExchange.c中找到下面的代碼）

static OSStatus 
SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams, 
                                 uint8_t *signature, UInt16 signatureLen) 
{ 
    OSStatus        err; 
    ... 
  
    if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0) 
        goto fail; 
    if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) 
        goto fail; 
        goto fail; 
    if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0) 
        goto fail; 
    err = sslRawVerify(ctx, 
                       ctx->peerPubKey, 
                       dataToSign,              /* plaintext */ 
                       dataToSignLen,           /* plaintext length */ 
                       signature, 
                       signatureLen); 
    if(err) { 
        sslErrorLog("SSLDecodeSignedServerKeyExchange: sslRawVerify " 
                    "returned %d\n", (int)err); 
        goto fail; 
    } 
  
fail: 
    SSLFreeBuffer(&signedHashes); 
    SSLFreeBuffer(&hashCtx); 
    return err; 
} 

注意，我高亮的地方，也就是那里有兩個goto fail; 因?yàn)閕f語句沒有加大括號，所以，只有第一個goto是屬于if的，而第二個goto則是永遠(yuǎn)都會被執(zhí)行到的（注：這里不是Python是C語言，縮進(jìn)不 代表這個語句屬于同一個語句塊）。也就是說，就算是前面的if檢查都失敗了（err  == 0），也會goto fail。我們可以看到fail標(biāo)簽中釋放完內(nèi)存后就會return err;

你想一下，這段程序在SSLHashSHA1.update()  返回成功，也就是返回0 的時候會發(fā)生什么樣的事？是的，真正干活的 sslRawVerify()被bypass了。而且這個函數(shù) SSLVerifySignedServerKeyExchange() 還返回了0，也就是成功了！尼瑪！你可能想到酷殼網(wǎng)上之前《一個空格引發(fā)的慘劇》的文章。都是低級bug。

這個低級bug在這個周末在網(wǎng)上被炒翻了天，你可以上Twiter上看看#gotofail的標(biāo)簽的盛況。Goto Fail必然會成為歷史上的一個經(jīng)典事件。

如果你喜歡XKCD，你一定會想到這個漫畫：

注意：這個bug不會影響TSL 1.2版本，因?yàn)?.2版本不會用這個函數(shù)，走的是另一套機(jī)制。但是別忘了client端是可以選擇版本的。

如果你想測試一下你的瀏覽器是否會有問題，你可以上一下當(dāng)天就上線的 https://gotofail.com 網(wǎng)站

一些思考

下面是我對這個問題的一些思考。

0）關(guān)于編譯報警

有人在說蘋果的這個代碼中的goto語句會產(chǎn)生死代碼——dead code，也就是永遠(yuǎn)都不會執(zhí)行到的代碼，C/C++的編程器是會報警的。但，實(shí)際上，dead code在默認(rèn)上的不會報警的。即使你加上-Wall，GCC 4.8.2 或 Clang 3.3 都不會報警，包括Visual Studio 2012在默認(rèn)的報警級別也不會（默認(rèn)是/W3級，需要上升到/W4級以上，但是升級到/W4上，你的工程可能會有N多的Warning，你不一定能看得 過來）。gcc和Clang有一個參數(shù)叫：-Wunreachable-code，是可以對這種情況報警的，但即沒有被包括在-Wall里。原因是，這個參數(shù)有很多的問題，因?yàn)榫幾g器的優(yōu)化代碼的行為，這個參數(shù)并不能對每種情況都準(zhǔn)確地報告。另請注意，GCC的新版本中剔除了這個參數(shù)。當(dāng)然，其它一些靜態(tài)的代碼檢查工具也可以檢查這個低級的問題。

另外，是不是用IDE的代碼自動化格式工具也可以幫上一點(diǎn)忙呢？至少可以把那個縮進(jìn)變成讓人一看就覺得有問題。

1）關(guān)于Code Merge 和 Code Review

你可以通過這里的代碼比較看到這個bug的diff，也可以到這里看看（631行）。

diff -urN <(curl -s http://opensource.apple.com/source/Security/Security-55179.13/libsecurity_ssl/lib/sslKeyExchange.c\?txt) \ <(curl -s http://opensource.apple.com/source/Security/Security-55471/libsecurity_ssl/lib/sslKeyExchange.c\?txt) \

通過code diff你可以看到，蘋果公司是在重構(gòu)代碼——為很多函數(shù)去掉了ctx的參數(shù)。

所以，我們可以猜測，兩個goto fail語句，可能是因?yàn)閷ode在不同branch上做merge發(fā)生的。版本工具merge代碼的時候，經(jīng)常性的會出現(xiàn)這樣的問題。如果代碼的 diff很多，這個問題會很容易就沒有注意到。就算有code review，這個有問題的代碼也很難被找出來的。如果你來review下面的diff，你會注意到這個錯誤嗎？

也就是說，在重構(gòu)分支上的代碼是對的，但是在分支merge的時候，被merge工具搞亂了。所以說，我們在做code merge的時候，一定要小心小心再小心，不能完全相信merge工具。

2）關(guān)于測試

很明顯，這個bug很難被code review發(fā)現(xiàn)。對于重構(gòu)代碼和代碼merge里眾多的diff，是很難被review的。

當(dāng)然，“事后諸葛亮”的人們總是很容易地說這個問題可以被測試發(fā)現(xiàn)，但是實(shí)際情況是這樣的嗎？

這個問題也很難被功能測試發(fā)現(xiàn)，因?yàn)檫@個函數(shù)在是在網(wǎng)絡(luò)握手里很深的地方，功能 測試不一定能覆蓋得那么深，你要寫這樣的case，必需對TSL的協(xié)議棧非常熟悉，熟悉到對他所有的參數(shù)都很熟悉，并能寫出針對每一個參數(shù)以及這些參數(shù)的 組合做一堆test case，這個事情也是一件很復(fù)雜的事。要寫出所有的case本身就是一件很難很難的事情。關(guān)于這個叫 SSLVerifySignedServerKeyExchange()函數(shù)的細(xì)節(jié)，你可以看看相關(guān)的ServerKeyExchange RFC文檔。

如果只看這個問題的話，你會說對這個函數(shù)做的 Unit Test 可以發(fā)現(xiàn)這個問題，是的。但是，別忘了SSL/TSL這么多年了，這些基礎(chǔ)函數(shù)都應(yīng)該是很穩(wěn)定的了， 在事前，我們可能不會想到要去為這些穩(wěn)定了多少年的函數(shù)寫幾個Unit Test。

只要有足夠多的時間，我們是可以對所有的功能點(diǎn)，所有的函數(shù)都做UT，也可以去追求做代碼覆蓋和分支覆蓋一樣。但有一點(diǎn)我們卻永遠(yuǎn)無法做到，那就是——窮舉所有的負(fù)面案例。所以，對于測試來說，我們不能走極端，需要更聰明的測試。就像我在《我們需要專職的QA》文章里的說過的——測試比coding難度大多了，測試這個工作只有高級的開發(fā)人員才做得好。我從來不相信不寫代碼的人能做好測試。

這里，我并不是說通過測試來發(fā)現(xiàn)這個問題的可能性不大，我想說的是，測試很重要，單測更重要。但是，我們無法面面俱到。在我們沒有關(guān)注到的地方，總會發(fā)生愚蠢的錯誤。

P.S.，在各大網(wǎng)站對這個事的討論中，我們可以看到OS X下的cul命令居然可以接受一個沒有驗(yàn)證過的IP地址的https的請求，雖然現(xiàn)在還沒有人知道這事的原因，但是，這可能是沒有在測試中查到的一個原因。

3）關(guān)于編碼風(fēng)格

對于程序員來說，在C語言中，省掉語句大括號是一件非常不明智 的事情。如我們強(qiáng)制使用語句塊括號，那么，這兩個goto fail都會在一個if的語句塊里，而且也容易維護(hù)并且易讀。（另外，通過這個bug，我們可以感受到，像Python那樣，用縮進(jìn)來表示語句塊，的確是 挺好的一件事）

也有人說，如果你硬要用只有單條語句，且不用語句塊括號，那么，這就是一條語句，應(yīng)該放在同一行上。如下所示：

if  (check_something)   do_something(); 

但是這樣一來，你在單步調(diào)試代碼的時候，就有點(diǎn)不爽了，當(dāng)你step over的時候，你完全不知道if的條件是真還是假。所以，還是分多行，加上大括號會好一些。

相似的問題，我很十多年前也犯過，而且那次我出的問題也比較大，導(dǎo)致了用戶的數(shù)據(jù)出錯。那次就是維護(hù)別人的代碼，別人的代碼就是沒有if的語句塊括號，就像蘋果的代碼那樣。我想在return z之前調(diào)用一個函數(shù)，結(jié)果就杯具了：

if ( ...... ) 
    return x; 
if ( ...... ) 
    return y; 
if ( ...... ) 
    foo() 
    return z; 

這個錯誤一不小心就犯了，因?yàn)槿说拇竽X會相當(dāng)然地認(rèn)為縮進(jìn)的都是一個語句塊里的。但是如果原來的代碼都加上了大括號，然后把縮進(jìn)做正常，那么對后面維護(hù)的人會是一個非常好的事情。就不會犯我這個低級錯誤了。就像下面的代碼一樣，雖然寫起來有點(diǎn)羅嗦，但利人利己。

if ( ...... ){ 
    return x; 
} 
if ( ...... ){ 
    return y; 
} 
if ( ...... ){ 
    return z; 
} 

與此類似的代碼風(fēng)格還有如下，你覺得哪個更容易閱讀呢？

• if (!p)    和  if (p == NULL)
• if (p)    和  if (p != NULL)
• if (!bflag)  和 if  (bflag == false)
• if ( CheckSomthing() )  和 if ( CheckSomething() == true )

所以說，代碼不是炫酷的地方是給別人讀的。

另外，我在想，為什么蘋果的這段代碼不寫成下面這樣的形式？你看，下面這種情況不也很干凈嗎？

if (  (err = ReadyHash(&SSLHashSHA1, &hashCtx)) != 0 ) 
       || (err = SSLHashSHA1.update(&hashCtx, &clientRandom)) != 0) 
       || (err = SSLHashSHA1.update(&hashCtx, &serverRandom) != 0) 
       || (err = SSLHashSHA1.update(&hashCtx, &signedParams) != 0) 
       || (err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)) { 
  
     goto fail; 
} 

其實(shí)，還可以做一些代碼上的優(yōu)化，比如，把fail標(biāo)簽里的那些東西寫成一個宏，這樣就可以去掉goto語句了。

4）關(guān)于goto語句

關(guān)于goto語句，1968年，Edsger Dijkstra 投了一篇文章到Communications of the ACM。原本的標(biāo)題是《A Case Against the Goto Statement》。CACM編輯Niklaus Wirth靈感來了，把標(biāo)題改為我們熟知的 《Go To Statement Considered Harmful》Dijkstra寫的內(nèi)容也是其一貫的犀利語氣，文中說：“幾年前我就觀察到，一個程序員的品質(zhì)是其程序中g(shù)oto語句的密度成反比的”，他還說，“后來我發(fā)現(xiàn)了為什么goto語句的使用有這么嚴(yán)重的后果，并相信所有高級語言都應(yīng)該把goto廢除掉。”  （花絮：因?yàn)?，這篇文章的出現(xiàn)，計算學(xué)界開始用’ X considered harmful ’當(dāng)文章標(biāo)題的風(fēng)潮，直到有人終于受不了為止）

為什么goto語句不好呢？Dijkstra說，一個變量代表什么意義要看其上下文。一個程序用N記錄房間里的人數(shù)，在大部分時候，N代表的是“目前房間里的人”。但在觀察到又有一個人進(jìn)房間后、把N遞增的指令前的這段程序區(qū)塊中，N的值代表的是“目前房間里的人數(shù)加一”。因此，要正確詮釋程序的狀態(tài)，必須知道程序執(zhí)行的歷史，或著說，知道現(xiàn)在“算到哪”了。

怎么談“算到哪了”？如果是一直線執(zhí)行下來的程序，我們只要手指一伸，說「到這里」，就可以了。如果是有循環(huán)程序，我們可能得說：“現(xiàn)在在循環(huán)的這個地方，循環(huán)已經(jīng)執(zhí)行了第i次”。如果是在函數(shù)中，我們可能得說：“現(xiàn)在執(zhí)行到函數(shù)p的這一點(diǎn)；p剛剛被q調(diào)用，調(diào)用點(diǎn)在一個循環(huán)中，這個循環(huán)已經(jīng)執(zhí)行了i次”。

如果有goto語句了呢？那就麻煩了。因?yàn)殡娔X在執(zhí)行某個指令前，可能是從程序中許許多多goto其中之一跳過來的。要談某變量的性質(zhì)也幾乎變得不可能了。這就是為什么goto語句問題。

Dijkstra的這篇文章對后面很多程序員有非常深的影響，包括我在內(nèi)，都覺得Goto語句能不用就不用，雖然，我在十年前的《編程修養(yǎng)》（這篇文章已經(jīng)嚴(yán)重過時，某些條目已經(jīng)漏洞百出）中的第23條也說過，我只認(rèn)為在goto語句只有一種情況可以使用，就是蘋果這個bug里的用法。但是我也同意Dijkstra，goto語句能不用就不用了。在更為高級的C++中，使用RAII技術(shù)，這樣的goto語句已經(jīng)沒有什么存在的意義了。

Dijkstra這篇文章后來成為結(jié)構(gòu)化程式論戰(zhàn)最有名的文章之一。長達(dá)19年之后，F(xiàn)rank Rubin投了一篇文章到CACM,標(biāo)題為《‘ Go To Considered Harmful’ Considered Harmful 》Rubin說，「雖然Dijkstra的說法既太學(xué)術(shù)又缺乏說服力」，卻似乎烙到每個程序員的心里了。這樣，當(dāng)有人說“用goto語句來解這題可能會比較好”會被嚴(yán)重鄙視。于是Rubin出了一道這樣的題：令X為N * N的整數(shù)陣列。如果X的第i行全都是零，請輸出i。如果不只一行，輸出最小的i .

Rubin找了一些慣用goto和不用goto的程序員來解題，發(fā)現(xiàn)用goto的程序又快又清楚。而不用goto通常花了更多的時間，寫出很復(fù)雜的解答。你覺得呢？ 另外，你會怎么寫這題的程序呢？

（花絮：以后幾個月的CACM熱鬧死了。編輯收到許多回應(yīng)，兩個月后刊出了其中五篇。文章也包括了《“‘GOTO Considered Harmful’ Considered Harmful” Considered Harmful? 》）

對于我而言，goto語句的弊遠(yuǎn)遠(yuǎn)大于利，在99%的情況下，我是站在反goto這邊的。

（花絮：這段時間，我在開發(fā)Nginx的模塊，因?yàn)橐郧皼]有做過，而且Nginx的開發(fā)文檔也不好，所以就得讀一些別人的源代碼。當(dāng)我看了一個某同學(xué)開發(fā)的nginx redis的模塊里的這段代碼 ngx_http_redis2_reply.c 看到里面飛沙走石的goto語句，我崩潰了！看到這樣的代碼，就像我在某個餐館看到了他那骯臟的廚房，無論你做菜的技藝有多高超，做的菜做得有多好看多好吃，我都惡心得一點(diǎn)也不想吃了）

總結(jié)

你看，我們不能完全消滅問題，但是，我們可以用下面幾個手段來減少問題：

1）盡量在編譯上發(fā)生錯誤，而不是在運(yùn)行時。

2）代碼是讓人讀的，順便讓機(jī)器運(yùn)行。不要怕麻煩，好的代碼風(fēng)格，易讀的代碼會減少很多問題。

3）Code Review是一件很嚴(yán)肅的事情，但 Code Reivew的前提條件是代碼的可讀性一定要很好。

4）測試是一件很重要也是很難的事情，尤其是開發(fā)人員要非常重視。

5）不要走飛線，用飛線來解決問題是可恥的！所以，用goto語句來組織代碼的時代過去了，你可以有很多種方式不用goto也可以把代碼組織得很好。

最后，我在淘寶過去的一年里，經(jīng)歷過一些P1/P2故障，尤其是去年的8-9月份，其中有70%的P1/P2故障，就是因?yàn)闆]有code review，沒有做好測試，大量地用飛線來解決問題，歸根結(jié)底就是只重業(yè)務(wù)結(jié)果，對技術(shù)沒有應(yīng)有的嚴(yán)謹(jǐn)?shù)膽B(tài)度和敬畏之心。

正如蘋果的這個“goto fail”事件所暗喻的，如果你對技術(shù)沒有應(yīng)用的嚴(yán)謹(jǐn)和敬畏之心，你一定會——

Go To Fail !!!

在這里嘮叨這么多，與大家共勉！

原文鏈接： http://coolshell.cn/articles/11112.html