Re: A secure Internet requires a secure network protocol
On Fri, 22 Jun 2007, Alex Alten wrote: Actually I think we need a shadow Internet that is used only for security purposes (and is fully encrypted). It is sort of like the old SS7 signaling infrastructure of the phone network. It doesn't need the same bandwidth, maybe 1/1000 or 1/10,000 as much. It would use strictly cryptographic protocols for identity authentication and key management, etc.. I don't think I agree that a fully encrypted net is for a security network only. Most of the attacks we see on protocols require one of the following properties: * packets can be inserted into the network that do not come from the machines they claim to have come from (spammers exploit SMTP) * packets are readable somewhere besides their intended destination. (criminals eavesdropping on secure transactions and logins) * packets can be easily modified in-flight (unethical ISPs or others exploit HTTP by inserting ads into documents that aren't supposed to have them). * authorization information is available in plaintext packets (killed telnet) These are (or were) protocols that EVERYBODY uses; not just security applications. If someone develops SIP (Secure Internet Protocol, in which all payload packets are encrypted end-to-end and completion of a secure key agreement protocol is required to initiate every payload packet stream) then running our network on TCP/SIP solves all of these issues. Further, merely encrypting a network doesn't make it suitable for a security network. Although that would solve a lot of problems with common protocol attacks, it doesn't really address authorization issues. It makes them easier to address, but by itself it doesn't do it. We think of security problems as being associated with machines, but security problems are really associated with users. What keys c are stored on the machine, in a security network, is not really appropriate information to rely on if a different user is sitting in front of it. A security network (or VPN done right) needs two more things: someone issuing fully revocable is-a-person credentials (indicating, roughly, that the bearer *IS* authorized to use this particular secure-net), and strict standards for how secured applications must work. Every packet needs to be traceable to the is-a-person credential (not just the machine) that was used to enter it on the network. I would be happiest if this credential were hardware: a passcard that you stick into a slot in the side of the machine in order to enable the secure-net, for example. But you still need support from secure applications. The applications must guarantee that the is-a-person credential is NEVER stored on the hard drive; your participant should have to enter it each time they enable the secure-net. And all the user profile information, browser settings, etc, should key off the is-a-person credential. If someone who is not using that credential changes a setting, it should have absolutely no effect on someone who is using that credential. And of course, 100% standard checking is required. Rejecting any non-standard-conforming packet or payload is flatly necessary. Once you have a secure-net, you kill another common problem: * problematic users can't be effectively and selectively banned - they just come back under a new pseudonym/account. (killing NNTP, SMTP, creating severe problems for SSL) The secure-net, without further modification, is then effectively an island within which NNTP, SMTP, FTP, SSL, HTTP, etc, can only see other systems on the same secure-net. I'm going to let other people think hard about the problems of establishing and controlling gateways between secure-nets. SSL seems to be hanging by a thread, mainly the name to public key mapping depends on how thorough the checking is done in to SSL vs application layers inside of the web browser. If this is hosed then unrestricted MITM is in the cards sometime in the near future. SSL is dying because the trust model implemented by its key certification process is horrifically clumsy from the user POV and the choices it presents are not meaningful to most people nor based on distinctions they can practically make. No information about the signing or trust policies in use by different signing authorities is generally available, and sadly, this is largely because there _is_ no information to convey about it. The sole thing that an SSL key establishes is that someone paid the signing authority money. Further, the signing authority is often some random unknown person whose name doesn't even appear on the cert, but who bought the key on a secondary market. Further still, the SSL keys themselves are bought and sold -- an SSL key is frequently in use by a person other than the person whose name appears on the cert, and the signing authorities do not track these further transfers nor revoke transferred keys. There is no root key whose further key-signing is
Re: A secure Internet requires a secure network protocol
Lynne or Anne, At 10:30 AM 6/22/2007 -0600, Anne Lynn Wheeler wrote: A secure Internet requires a secure network protocol http://www.infoworld.com/article/07/06/22/25OPsecadvise_1.html Actually I think we need a shadow Internet that is used only for security purposes (and is fully encrypted). It is sort of like the old SS7 signaling infrastructure of the phone network. It doesn't need the same bandwidth, maybe 1/1000 or 1/10,000 as much. It would use strictly cryptographic protocols for identity authentication and key management, etc.. one of the things seen in various of the SSL (authentication) vulnerabilities SSL seems to be hanging by a thread, mainly the name to public key mapping depends on how thorough the checking is done in to SSL vs application layers inside of the web browser. If this is hosed then unrestricted MITM is in the cards sometime in the near future. - Alex -- Alex Alten [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A secure Internet requires a secure network protocol
Alex Alten wrote: SSL seems to be hanging by a thread, mainly the name to public key mapping depends on how thorough the checking is done in to SSL vs application layers inside of the web browser. If this is hosed then unrestricted MITM is in the cards sometime in the near future. re: http://www.garlic.com/~lynn/aadsm27.htm#29 A secure Internet requires a secure network protocol i.e. we were called in to consult with this small client/server startup that wanted to do payments on their server. they had this technology they called SSL ... and we had to end-to-end process audits ... including walk-thru of some of these new business entities that were calling themselves certification authorities. http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn3 the fundamental SSL design point was that the user knows the relationship between a website and a URL, the user entered that URL, and SSL would authenticate that the website that the user *thot* they were talking to (from entering the URL), was in fact, the website they were actually talking to. these days, most users have no cognition about relationship between websites and URLs, they click on something in email and/or webpages. In this scenario, the attacker is providing the URL and then the only thing that SSL is providing is authenticating who the attacker is claiming to be (via the URL that the attacker provides). the original SSL design point had implicit assumptions that users knew the relationship between the website they thot they were talking to and URLs (and then SSL authenticated the relationship between those known URLs and the website). For the most part those assumptions are no longer valid ... which then breaks the security model and all bets are off. With the potential attacker frequently providing both the URL and the website, then the only thing SSL is providing is authenticating the website that the attacker claims to be (via the URL) is the website that they are (breaking original basic assumption about SSL). This totally invalidates the assumption that SSL is proving that the website that the user *thot* they were talking to (via directly entering the URL) was, in fact, the website that they were talking to (aka the user has no idea what website they are talking to ... because they no longer have the knowledge about the relationship between websites they think they are talking to and the URLs for those websites). The (*URL*) name to key mapping isn't the problem ... that is the mechanics that SSL provided. The problem was that SSL security had implicit assumption that the user knew the mapping between the website they think they talk to and the URL for that website. In the current environment, that assumption is no longer valid, So the basic, most common PKI infrastructures provide a trusted public key repository (typically manufactured into browsers before they ship). Users are indoctrinated that they can trust those public keys ... for the purposes of digitally signing digital certificates. These digital certificates provide the binding between URL (actually the domain names part of URL) and website public keys. It is imperative that the user (knowledge) then provide the binding the website they think they are talking to and the URL. That is the part that is missing in today's environment (and what large numbers of attackers can leverage to slip thru the cracks). The missing piece is trusted binding between who the user's think they are talking to and the URL (or at least domain name). This could be accomplished by a separate trusted repository ... names that the end-user relates to and trusted binding between those names and URLs. Attacker provided URLs that are clicked on ... then can be cross-checked with things in that new trusted table (analogous to the way that the browser table of certification authority public keys are trusted). Then the issue is that if there is a trusted table mapping names to URLs (or at least domain names) ... and a separate table of trusted public keys ... the whole thing could be collapsed into a single table ... totally eliminating the level of indirection provided by (redundant and superfluous) PKI and certification authorities ... just add the public key to the trusted table of names domain names (aka URLs). The issue isn't so much that SSL is broken ... it is the implicit dependency on users knowing the relationship between the website they think they were talking to and the URL for those websites. Creating a user trusted table of website/urls (analogous to the browser trusted table of certification authority public keys), can make PKIs and certification authorities redundant and superfluous ... since in whatever trusted process is used to maintain the trusted table of website/urls ... can also directly include the public key for those website/urls. this is similar, but different to some of the domain name
A secure Internet requires a secure network protocol
A secure Internet requires a secure network protocol http://www.infoworld.com/article/07/06/22/25OPsecadvise_1.html from above: Implementing -- and requiring -- stronger authentication and cryptography standards is the next step toward a new Internet ... snip ... i would contend that majority of exploits are attacks on (vulnerable) end-points ... not directly involving any actual network protocol or cryptography; this includes (updated) variations on old-time social engineering ... which has some relation to authentication (between end-points) ... but on par with crooks using the telephone to call people and convince them of one thing or another (and then suggesting that encrypting the telephone call transmission would eliminate the problem). one of the things seen in various of the SSL (authentication) vulnerabilities ... are attackers being able to (authenticate) prove who they claim to be ... however, who they claim to be for SSL authentication ... and who they claim to be for their social engineering attacks ... may not be exactly the same. As before, one of the largest class of attacks (not restricted to internet) are against information related to payment transactions and which (largely because of weak authentication in unrelated parts of the infrastructure) is then turned around and relatively easily used for fraudulent financial transactions. misc. past posts on the theme of naked transactions. http://www.garlic.com/~lynn/subintegrity.html#payment - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
