Please allow me to introduce myself. I am neither a CIPE developer nor a cryptanalysis expert. I am however a security consultant who deals primarily in Free/Open Source Software. I have used CIPE in the past as well as other Free/Open/Non-Free products for use in a VPN solutions. I wanted to contribute an outsiders perspective. I first read Peter Gutmanns analysis [1] as linked from Slashdot [2] and later I found the archive for cipe-l [3]. After reading Gutmann's short but to the point email a few points that he made seemed obvious. Some of the flaws were not so obvious. CIPE seemed to have some very simple flaws and some of the fixes were easy to implement. I found a some of it delivered in such a manner that would upset people who were highly vested in the projects he was criticizing. Perhaps it was the comment that I also found to be so amusing, something to do with sound waves. Amusing as it may be, it's still quite harsh. I then read through the posts on Slashdot that declared CIPE to be dead. I found these to be really immature and silly considering the nature of F/OSS. The need for some change is now, not the time for it's funeral. Thanks to the F/OSS method of development this is all very possible. The only series of comments on Slashdot worth reading (IMHO) were by Dan Kaminsky [4]. I also went ahead and read the CIPE FAQ [5]. A few statements seemed a little hard to believe after Gutmanns pointing out of using CRC-32 (as opposed to say SHA1). These really stuck out: "To date one case of a potentially exploitable bug has been found, luckily in a version which never was widely used. Another bug has been found which could lead to denial of service attacks. Both have been fixed." [...] "As for CIPE vs. IPSEC, they should be equivalent security-wise, with CIPE giving a bit better performance because of the lightweight protocol." Peter Gutmann had stated that some of his findings were actually found years prior, thus the first statement seems to be false. The second statement is just a bald faced lie, unless it was written by someone from a decade ago. The CIPE protocol description [6] says outright that CIPE uses CRC-32 for *integrity protection*. An important statement to take into account from the protocol description: "The primary goal of this software is to provide a facility for secure (against eavesdropping, including traffic analysis, and faked message injection) subnetwork interconnection across an insecure packet network such as the Internet." With that said and with the analysis by Gutmann, let's get onto the list. The list I assumed would be delighted to have a professional cryptographer take a look at their tool of choice. I think the going rate for an actual security audit by a trained professional is somewhere around $60,000 (USD). This is a security related tool and as such needs this type of attention. Tools that would not like this type of audit might as well be snake oil. However deep this audit went, it does point out a number of problems. Actual problems that need to be addressed for the users of CIPE and fixes that need to be coded by the developers. Some of them are very valid at the time of writing, some of them are not practical without using a stateless encryption system (as Dan Kaminsky explains in his Slashdot posts). There are (as of this writing time) three major threads on the subject of Gutmanns email. The major first thread has responses ranging from defending CIPE and understanding the authors stated claims [7]. The author of this post creates a nice numbered list to respond to. He misunderstands the statement about CIPE being "Linux's answer to MS-PPTP." He also goes on to start questioning Gutmann about things including message insertion. It also extends to a personal attack about Gutmanns ego. The message is then summed up as: "The bottom line for me is that CIPE is not less secure compared to many commercial products. The CIPE protocol is not that easy to break as suggested by Gutmann, but the protocol surely has room for improvements. If you enable data compression (CipeX) it is even more complicated to break the protocol: you first need to decrypt to de-compress, and it is extremely difficult to guess the contents of a compressed ip-packet, which guessed content is needed to break the encryption." These statements are preposterous. With an arbitrary comparison to "many commercial products," whatever metric that is. That it's "hard" for "someone" to break, but that it's still very much possible. Being alright with this is quite amazing. This is a security project. Difficulty is very relative and for Johnny hacker, it might be hard. However an example of making it hard to decrypt by using compression is a great example of misunderstanding. A UDP packet with a static key that has a compressed payload can be replayed over and over and over again. No key required. The compression isn't going to be a secret either right? So it's still going to be possible to do plain text attacks of the same magnitude regardless of the way the data is before cyphers are applied. The follow ups to this are much like a rally behind a weak player [8] with a few exceptions [9]. Others want to wait for Olaf (the primary author of CIPE) to speak on this issue before making any major conclusions [10]. Some people are thanking for tool that has some major flaws as pointed out by a well respected cryptographer [11] and some think it could be pro money making FUD [12]. The fact that Olaf hasn't replied is a huge problem for my assurances that this project is on track to fix these problems, I know that I am not alone [13]. What is more shocking to me is the lack of understanding about a protocol/security method being broken. It seems that many people doing small tests of their own [14] find it to be acceptable because it will fit their clients needs. Their own greed and the ease of setup being the bottom line. Other people seem just fine with CIPE being "less than a bank vault" and I find this just amazing [15]. This is a project that claims the highest in industry stands. These are people giving away secure systems. That type of response is insane. One poster even seemed happy with these statements against CIPE and bragged of it's use in "every sector you can imagine" [16]. Perhaps the most together response has been by someone running a small company who had customers upset by Gutmanns statements [17]. This person acknowledges many of the concerns but down plays some of the more important ones. Statements that Gutmann is playing up the CRC-32 problems (in relation to SSHv1) making it sensationalist are invalid. This is very much a valid concern. However he does a great run down of the concerns and is very much an important statement. Gutmann himself writes "A Coda to "Linux's answer to MS-PPTP" [18]." This is a well thought out response to the letters he has no doubt been flooded by. This product has been adopted by people around the world who may or may not depend on it as much as the next person. This however says to me that it's very important to have a response by Olaf, fixes implemented and even though Gutmann was rude, he should be thanked. If these fixes are implemented, people who depend on CIPE will have something that is not broken. It is clearly broken and it needs to be addressed, users need to be alerted. A proof of concept should not be needed in this case. I imagine however that it won't be very long before someone writes a proof of concept ettercap plug-in to mess with CIPE if this isn't fixed. People depend on software like CIPE and it can cost them dearly if situations like this aren't fixed. It's not always about business either, sometimes lives are at stake. Those people might not stand up and demand something be done, but someone should. Let us make sure that this gets fix. Let us also make sure that this situation is handled well and discussed openly. If it's ignored, we can know that the relation of CIPE to snake oil is inversely proportional to the amount of work spent fixing it by it's project leads. [1] http://www.mit.edu:8008/bloom-picayune/crypto/14238 [3] http://slashdot.org/article.pl?sid=03/09/22/2127236 [3] http://sites.inka.de/bigred/archive/cipe-l/2003-09/threads.html [4] http://slashdot.org/comments.pl?sid=79554&cid=7029635&pid=7029635&startat=&threshold=1&mode=nested&commentsort=0&op=Change [5] http://sites.inka.de/sites/bigred/devel/cipe-faq.html [6] http://sites.inka.de/sites/bigred/devel/CIPE-Protocol.txt [7] http://sites.inka.de/bigred/archive/cipe-l/2003-09/msg00200.html [8] http://sites.inka.de/bigred/archive/cipe-l/2003-09/msg00211.html [9] http://sites.inka.de/bigred/archive/cipe-l/2003-09/msg00193.html [10] http://sites.inka.de/bigred/archive/cipe-l/2003-09/msg00194.html [11] http://sites.inka.de/bigred/archive/cipe-l/2003-09/msg00197.html [12] http://sites.inka.de/bigred/archive/cipe-l/2003-09/msg00227.html [13] http://sites.inka.de/bigred/archive/cipe-l/2003-09/msg00228.html [14] http://sites.inka.de/bigred/archive/cipe-l/2003-09/msg00192.html [15] http://sites.inka.de/bigred/archive/cipe-l/2003-09/msg00203.html [16] http://sites.inka.de/bigred/archive/cipe-l/2003-09/msg00209.html [17] http://sites.inka.de/bigred/archive/cipe-l/2003-09/msg00225.html [18] http://www.mit.edu:8008/bloom-picayune/crypto/14258 -- Jake Appelbaum <jacob@xxxxxxxxxxxxx>
Attachment:
signature.asc
Description: This is a digitally signed message part