Re: User interface, security, and simplicity
On Wed, May 07, 2008 at 10:27:48AM +1000, James A. Donald wrote: Dynamic strings tempt people to forget about enforcing length limits and forget about correctly handling the case when the length limits are exceeded. This too is dealt with. Message sizes are bounded, recipient counts are bounded, duplicate elimination cache sizes are bounded, command lengths are bounded, logical header lengths are bounded, body content is processed 2K bytes at a time... The requirement is stronger than just not running a single process out of memory, the entire multi-process Postfix is designed to run in (realistic) bounded memory (no fork: out of memory). -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: User interface, security, and simplicity
James A. Donald [EMAIL PROTECTED] writes: In any program subject to attack, all strings should have known, documented, and enforced maximum length, a length large enough for all likely legitimate uses, and no larger. Precisely. An example of where dynamic strings can lead you is what happens to old (very old) versions of Netscape when you feed them a cert with, say, an MPEG of a cat in the X.500 DN. Netscape happily accepts the cert but you then have to reinstall the browser because while it'll quite readily accept ridiculously long values it doesn't actually cope with them very well. A security component that's trivially taken out by a DoS isn't a security component, it's a vulnerability. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: User interface, security, and simplicity
On Sun, May 04, 2008 at 10:24:13PM -0400, Thor Lancelot Simon wrote: I believe that those who supply security products have a responsibility to consider the knowledge, experience, and tendencies of their likely users to the greatest extent to which they're able, and supply products which will function properly _as users are likely to apply them_. The TLS support in Postfix tries to behave sensibly with easy setings. - Cipher list selection is indirect, via grades: export, low, medium and high. The actual ciphers for each grade are buried in parameters users are advised to not mess with. - The cipher grade for opportunistic TLS is export, but you single out a destination for mandatory TLS, the grade rises to medium. - The secure peer cert validation level compares the peer's cert to the nexthop domain (allowing a sub-domain match by default). Hostnames derived from MX lookups are of course subject to DNS MITM and are not trusted. If you want to trust your DNS you can use verify instead. http://www.postfix.org/TLS_README.html#client_tls_limits http://www.postfix.org/TLS_README.html#client_tls_may http://www.postfix.org/TLS_README.html#client_tls_encrypt http://www.postfix.org/TLS_README.html#client_tls_verify http://www.postfix.org/TLS_README.html#client_tls_secure - With the upcoming EECDH support, users don't choose curves directly, they again choose a security grade, and the correspnding curves are configurable via parameters they are not expected to ever look at or modify. If you don't botch your CAfile, it is rather easy to provision secure-channel connections to a select set of high-value peers. If you don't trust any CAs: http://www.postfix.org/TLS_README.html#client_tls_fingerprint once you have a system designed in all its features to behave sensibly by default (e.g. with an empty main.cf file), making security behave sensibly by default is not that unnatural. So I think there should be a broad design bias towards *implicit* correct behaviour in all system features, with rope available for advanced users to *explicitly* craft more complex use-cases. Once you have that, practical security is not too difficult. The same is true in the source code, unsafe practices are avoided globally, (e.g. both strcpy() and strncpy() are absent together with fixed size automatic buffers) rather than used with care locally. I won't bore you with all the implementation safety habits, but there are many. -- Viktor. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: User interface, security, and simplicity
On Sun, 04 May 2008 11:22:51 +0100 Ben Laurie [EMAIL PROTECTED] wrote: Steven M. Bellovin wrote: On Sat, 03 May 2008 17:00:48 -0400 Perry E. Metzger [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Peter Gutmann) writes: I am left with the strong suspicion that SSL VPNs are easier to configure and use because a large percentage of their user population simply is not very sensitive to how much security is actually provided. They're easier to configure and use because most users don't want to have to rebuild their entire world around PKI just to set up a tunnel from A to B. I'm one of those people who uses OpenVPN instead of IPSEC, and I'm one of the people who helped create IPSEC. Right now, to use SSH to remotely connect to a machine using public keys, all I have to do is type ssh-keygen and copy the locally generated public key to a remote machine's authorized keys file. When there is an IPSEC system that is equally easy to use I'll switch to it. Until then, OpenVPN let me get started in about five minutes, and the fact that it is less than completely secure doesn't matter much to me as I'm running SSH under it anyway. There's a technical/philosophical issue lurking here. We tried to solve it in IPsec; not only do I think we didn't succeed, I'm not at all clear we could or should have succeeded. IPsec operates at layer 3, where there are (generally) no user contexts. This makes it difficult to bind IPsec credentials to a user, which means that it inherently can't be as simple to configure as ssh. Put another way, when you tell an sshd whom you wish to log in as, it consults that user's home directory and finds an authorized_keys file. How can IPsec -- or rather, any key management daemon for IPsec -- do that? Per-user SPDs? Is this packet for port 80 for user pat or user chris? I can envision ways around this (especially if we have an IP address per user of a system -- I've been writing about fine-grained IP address assignment for years), but they're inherently a lot more complex than ssh. I don't see why. The ssh server determines who the packets are for from information sent to it by the ssh client. The ssh client knows on whose behalf it is acting by virtue of being invoked by that user (I'll admit this is a simplification of the most general case, but I assert my argument is unaffected), and thus is able to include the information when it talks to the server. Similarly, the client end of an IPSEC connection knows who opened the connection and could, similarly, convey that information. That data may not be available in some OSes by the time it gets to the IPSEC stack, but that's a deficiency of the OS, not a fundamental problem. The problem is more on the server end. --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: User interface, security, and simplicity
On Sat, 03 May 2008 19:50:01 -0400 Perry E. Metzger [EMAIL PROTECTED] wrote: Almost exclusively the use for such things is nailing up a tunnel to bring someone inside a private network. For that, there is no need for per user auth -- the general assumption is that the remote box is a single user laptop or something similar anyway. You really just want to verify that the remote host has a particular private key, and if it does, you nail up a tunnel to it (possibly allocating it a local IP address in the process). That solves about 95% of the usage scenarios and it requires very little configuration. It also covers virtually all use of IPSec I see in the field. Again, there are more complex usage scenarios, and it may be more complicated to set one of *those* up, but it is a shame that it is difficult to do the simple stuff. So here's an interesting experiment. Part one: Take a common IPsec implementation -- Linux, *BSD, Windows, what have you. Assume this common scenario: laptop connecting to a corporate server. Assume a user authentication credential. (I'd prefer that that be a public/ private key pair, for many reasons, not the least of which is the bug in IKEv1 with main mode and shared secrets.) Do not assume a 1:1 ratio between laptops and internal IP address, because such servers are frequently underprovisioned. Challenge: design -- and implement -- a *simple* mechanism by which the client user can set up the VPN connection, both on the client and on the server. This part can happen while the client is physically on the corporate net. Variant A: the VPN server is a similar box to which the client has login-grade access. Variant B: the VPN server is something like a restricted-access Cisco box, in which case a trusted proxy is probably needed. User setup should be something like 'configvpn cs.columbia.edu', where I supply my username and authenticator. User connection should be 'startvpn cs.columbia.edu' (or, of course, the GUI equivalent); all I supply is some sort of authenticator. Administrator setup should be a list of authorized users, and probably an IP address range to use (though having the VPN server look like a DHCP relay would be cool). Experiment part two: implement remote login (or remote IMAP, or remote Web with per-user privileges, etc.) under similar conditions. Recall that being able to do this was a goal of the IPsec working group. I think that part one is doable, though possibly the existing APIs are incomplete. I don't think that part two is doable, and certainly not with high assurance. In particular, with TLS the session key can be negotiated between two user contexts; with IPsec/IKE, it's negotiated between a user and a system. (Yes, I'm oversimplifying here.) --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: User interface, security, and simplicity
On Tue, May 06, 2008 at 03:40:46PM +, Steven M. Bellovin wrote: In particular, with TLS the session key can be negotiated between two user contexts; with IPsec/IKE, it's negotiated between a user and a system. (Yes, I'm oversimplifying here.) Is there any reason (in principle) that IPsec/IKE could not be done entirely in userspace / application space, though? -Jack - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
User interface, security, and simplicity
In article [EMAIL PROTECTED] you write: On Sun, May 04, 2008 at 10:24:13PM -0400, Thor Lancelot Simon wrote: I believe that those who supply security products have a responsibility to consider the knowledge, experience, and tendencies of their likely users to the greatest extent to which they're able, and supply products which will function properly _as users are likely to apply them_. The TLS support in Postfix tries to behave sensibly with easy setings. - Cipher list selection is indirect, via grades: export, low, medium and high. The actual ciphers for each grade are buried in parameters users are advised to not mess with. - The cipher grade for opportunistic TLS is export, but you single out a destination for mandatory TLS, the grade rises to medium. [..] - With the upcoming EECDH support, users don't choose curves directly, they again choose a security grade, and the correspnding curves are configurable via parameters they are not expected to ever look at or modify. This struck me as poor design, not good design. Asking the user to make these kinds of choices seems like the kind of thing that only a cryptographer could consider sensible. In this day and age, software should not be asking users to choose ciphers. Rather, the software should just pick a sensible high-grade security level (e.g., AES-128, RSA-1024 or RSA-2048) and go with that, and avoid bothering the user. Why even offer low as an option? (And this export business sounds like a throwback to a decade ago; why is that still there?) Good crypto is cheap. Asking a user is expensive and risky. So I think there should be a broad design bias towards *implicit* correct behaviour in all system features, with rope available for advanced users to *explicitly* craft more complex use-cases. Once you have that, practical security is not too difficult. Amen. I know of quite a few software packages that could use more of that philosophy. The same is true in the source code, unsafe practices are avoided globally, (e.g. both strcpy() and strncpy() are absent together with fixed size automatic buffers) rather than used with care locally. I won't bore you with all the implementation safety habits, but there are many. It's too bad that today such elementary practices are something to brag about. Perhaps one day we'll be lucky enough that the answer to these questions becomes more like of course we use safe programming practices; what kind of incompetent amateurs do you take us for?. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: User interface, security, and simplicity
On Tue, May 06, 2008 at 03:40:46PM +, Steven M. Bellovin wrote: Experiment part two: implement remote login (or remote IMAP, or remote Web with per-user privileges, etc.) under similar conditions. Recall that being able to do this was a goal of the IPsec working group. I think that part one is doable, though possibly the existing APIs are incomplete. I don't think that part two is doable, and certainly not with high assurance. In particular, with TLS the session key can be negotiated between two user contexts; with IPsec/IKE, it's negotiated between a user and a system. (Yes, I'm oversimplifying here.) Connection latching and connection-oriented IPsec APIs can address this problem. Solaris, and at least one other IPsec implementation (OpenSwan? I forget) makes sure that all packets for any one TCP connection (or UDP connection) are protected (or bypassed) the same way during their lifetime. The same way - by similar SAs, that is, SAs with the same algorithms, same peers, and various other parameters. A WGLC is about to start in the IETF BTNS WG on an I-D that describes this. Nico -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: User interface, security, and simplicity
On Tue, May 06, 2008 at 11:40:53AM -0700, David Wagner wrote: - With the upcoming EECDH support, users don't choose curves directly, they again choose a security grade, and the correspnding curves are configurable via parameters they are not expected to ever look at or modify. This struck me as poor design, not good design. Asking the user to make these kinds of choices seems like the kind of thing that only a cryptographer could consider sensible. They are not *asked* to make any cipher choices. The are able to make: - no explicit choice, and get sensible default behaviour - a high level choice (secure verification + high grade cipher without having to spell out the gory details of what these mean. - an exteremely detailed specification of all the details. In this day and age, software should not be asking users to choose ciphers. The users in question are email administrators, not end users, and you missed my point. They are not asked to choose ciphers, these are chosen for them, and the default choice is even context dependent, so you get sensible combinations of security properties: - Opportunistic TLS allows SSLv2 and export ciphers - Mandatory TLS, enforces SSLv3/TLSv1 and medium or high ciphers. Rather, the software should just pick a sensible high-grade security level (e.g., AES-128, RSA-1024 or RSA-2048) and go with that This is what is done (using OpenSSL's HIGH, MEDIUM, ... selectors). and avoid bothering the user. Why even offer low as an option? (And this export business sounds like a throwback to a decade ago; why is that still there?) You don't know how TLS is used with SMTP. Most TLS is opportunistic and plain text is used if TLS is absent. In such an environment insisting on 128 bits is silly, even 40 bits is better than plain-text. Good crypto is cheap. Asking a user is expensive and risky. Breaking interoperability by limiting cipher selection and causing mail to queue is not cheap. So I think there should be a broad design bias towards *implicit* correct behaviour in all system features, with rope available for advanced users to *explicitly* craft more complex use-cases. Once you have that, practical security is not too difficult. Amen. I know of quite a few software packages that could use more of that philosophy. The same is true in the source code, unsafe practices are avoided globally, (e.g. both strcpy() and strncpy() are absent together with fixed size automatic buffers) rather than used with care locally. I won't bore you with all the implementation safety habits, but there are many. It's too bad that today such elementary practices are something to brag about. Perhaps one day we'll be lucky enough that the answer to these questions becomes more like of course we use safe programming practices; what kind of incompetent amateurs do you take us for?. Practices are culture not technology, and it is difficult to displace existing cultures with new ones :-( -- Viktor. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: User interface, security, and simplicity
The same is true in the source code, unsafe practices are avoided globally, (e.g. both strcpy() and strncpy() are absent together with fixed size automatic buffers) rather than used with care locally. I won't bore you with all the implementation safety habits, but there are many. David Wagner wrote: It's too bad that today such elementary practices are something to brag about. Perhaps one day we'll be lucky enough that the answer to these questions becomes more like of course we use safe programming practices; what kind of incompetent amateurs do you take us for?. Dynamic strings tempt people to forget about enforcing length limits and forget about correctly handling the case when the length limits are exceeded. There is no such thing as a string with no maximum length, merely strings of UNKNOWN maximum length. If one has dynamic buffers and fully dynamic strings, it is always possible for an attacker to discover the previously UNKNOWN maximum length, and exceed it, causing the program to fail in a manner likely to be useful to the attacker. In any program subject to attack, all strings should have known, documented, and enforced maximum length, a length large enough for all likely legitimate uses, and no larger. If enforcing length limits, it is frequently advisable, and often necessary, to use, not strcpy or strncpy, but routines such as _mbscpy_s, string manipulation routines which can, and frequently do, employ buffers of fixed and known length, sometimes pre-allocated fixed length. In C++, incomprehensibly obscure functions such as _mbscpy_s should never be called directly, but rather called through a template library that automatically does the sensible thing when the destination parameter is a fixed length buffer, and can be relied upon to object when commanded to do the stupid thing. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: User interface, security, and simplicity
Steven M. Bellovin wrote: IPsec operates at layer 3, where there are (generally) no user contexts. This makes it difficult to bind IPsec credentials to a user, which means that it inherently can't be as simple to configure as ssh. Put another way, when you tell an sshd whom you wish to log in as, it consults that user's home directory and finds an authorized_keys file. How can IPsec -- or rather, any key management daemon for IPsec -- do that? Per-user SPDs? Is this packet for port 80 for user pat or user chris? I can envision ways around this (especially if we have an IP address per user of a system -- I've been writing about fine-grained IP address assignment for years), but they're inherently a lot more complex than ssh. This is a particular case of the layer problem I have been ranting about for years: Private and authenticated sessions at layer X do not in themselves correspond to private and authenticated sessions at layer Y, and for users to arrange their affairs so that layer X does indeed secure layer Y generally requires users to stand on their heads and stick their right big toe in their left ear. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: User interface, security, and simplicity
Ian G wrote: (on Kerckhoffs's rules) = 6. Finally, it is necessary, given the circumstances that command its application, that the system be easy to use, requiring neither mental strain nor the knowledge of a long series of rules to observe. = ... PS: Although his 6th is arguably the most important Yes. Usability should be the #1 property of a secure system. Conventional security thinking says that usability and security are like a seesaw; if usability goes up, security must go down, and vice-versa. This apparent antinomy actually works as a synergy: with more usability in a secure system, security increases. With less usability in a secure system, security decreases. A secure system that is not usable will be left aside by users. Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: User interface, security, and simplicity
Thor Lancelot Simon wrote: And, in fact, most VPN software of any type fails this test. My concern is that an excessive focus on how hard is it to set this thing up? can seriously obscure the important second half of the question and if you set it up in the easiest possible way, is it safe? If there is a wrong way to do it, the end user will do it wrong. Expert cryptographers frequently fail to act correctly on their understanding of cryptography. The end user has no chance - and the chances are still not all that good even if your end user is highly qualified cryptographer. What users comprehend, and are used to, is you that set up an account with username and password, and an admin blesses the account with appropriate privileges as a result of some out of band communication - which username and password has to be secured, invisibly to the user, against offline and phishing attacks, without requiring any thought or vigilance by the user - see my web page for http://jim.com/security/how_to_do_VPNs.html for attacks on the password model, and defenses against those attacks. This comes naturally to humans, for humans have long relied on shibboleths for security against treachery by outsiders. Thus the computer interface to our clever cryptographic algorithms must resemble as closely as possible the ancient human reliance on shibboleths for security. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: User interface, security, and simplicity
Steven M. Bellovin wrote: On Sat, 03 May 2008 17:00:48 -0400 Perry E. Metzger [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Peter Gutmann) writes: I am left with the strong suspicion that SSL VPNs are easier to configure and use because a large percentage of their user population simply is not very sensitive to how much security is actually provided. They're easier to configure and use because most users don't want to have to rebuild their entire world around PKI just to set up a tunnel from A to B. I'm one of those people who uses OpenVPN instead of IPSEC, and I'm one of the people who helped create IPSEC. Right now, to use SSH to remotely connect to a machine using public keys, all I have to do is type ssh-keygen and copy the locally generated public key to a remote machine's authorized keys file. When there is an IPSEC system that is equally easy to use I'll switch to it. Until then, OpenVPN let me get started in about five minutes, and the fact that it is less than completely secure doesn't matter much to me as I'm running SSH under it anyway. There's a technical/philosophical issue lurking here. We tried to solve it in IPsec; not only do I think we didn't succeed, I'm not at all clear we could or should have succeeded. IPsec operates at layer 3, where there are (generally) no user contexts. This makes it difficult to bind IPsec credentials to a user, which means that it inherently can't be as simple to configure as ssh. Put another way, when you tell an sshd whom you wish to log in as, it consults that user's home directory and finds an authorized_keys file. How can IPsec -- or rather, any key management daemon for IPsec -- do that? Per-user SPDs? Is this packet for port 80 for user pat or user chris? I can envision ways around this (especially if we have an IP address per user of a system -- I've been writing about fine-grained IP address assignment for years), but they're inherently a lot more complex than ssh. I don't see why. The ssh server determines who the packets are for from information sent to it by the ssh client. The ssh client knows on whose behalf it is acting by virtue of being invoked by that user (I'll admit this is a simplification of the most general case, but I assert my argument is unaffected), and thus is able to include the information when it talks to the server. Similarly, the client end of an IPSEC connection knows who opened the connection and could, similarly, convey that information. That data may not be available in some OSes by the time it gets to the IPSEC stack, but that's a deficiency of the OS, not a fundamental problem. It seems to me there's no real difference between the two cases. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: User interface, security, and simplicity
On Sat, 2008-05-03 at 23:35 +, Steven M. Bellovin wrote: There's a technical/philosophical issue lurking here. We tried to solve it in IPsec; not only do I think we didn't succeed, I'm not at all clear we could or should have succeeded. IPsec operates at layer 3, where there are (generally) no user contexts. This makes it difficult to bind IPsec credentials to a user, which means that it inherently can't be as simple to configure as ssh. Let me restate things just to make sure I understand the problem. You're talking about binding IPsec credentials to a user, but I want to look at it from the point of view of exactly what problems this causes, so is the following an accurate position? The problem is that we're trying to have entities with different security needs share a common set of authentications. When user 'pat' and user 'sandy' have different security needs (different authorized or trustable communication partners, to start with) we can't give them IPSEC because IPSEC operates on channels between machines rather than on channels between trusting/trusted entities. Even if 'pat' and 'sandy' both have a trusted/trusting entity on a given remote machine from theirs, IPSEC fails them because it cannot differentiate between the various entities (users, agents, services) using that remote machine, when 'pat' and 'sandy' need it to. Similarly, it fails the entities on that remote machine because it cannot differentiate between 'pat', 'sandy' and any other entities using the local machine, when trust relationships might exist only for some subset of those entities. Bear - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: User interface, security, and simplicity
Jacob Appelbaum [EMAIL PROTECTED] writes: Perry E. Metzger wrote: Until then, OpenVPN let me get started in about five minutes, and the fact that it is less than completely secure doesn't matter much to me as I'm running SSH under it anyway. [...] I'm always curious to hear what designers of protocols actually use on a daily basis. I'm also really curious how said designers evaluate their choices. I really like OpenVPN. It's really smooth to setup, it's very easy to use on the Big Three Platforms. Have you read the source to OpenVPN? Do you think that it's cryptographically sound? Is it properly implemented? I've found some stuff I wonder about and I'm curious if anyone else has? I can't claim to like the innards, and it seems bizarre to me that the designers didn't simply use IPSec encapsulated in UDP as the underlying protocol. (Were I writing such a thing today, I might use DTLS.) That said, in my usage pattern, I don't care much about the possible security flaws. I would not recommend the package to clients, however. It is obvious to anyone using modern IPSec implementations that their configuration files are a major source of pain. In spite of this, the designers don't seem to see any problem. The result has been that people see IPSec as unpleasant and write things like OpenVPN when the underlying IPSec protocol is just fine and it is the implementations that are unpleasant. -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: User interface, security, and simplicity
On Sat, May 03, 2008 at 07:50:01PM -0400, Perry E. Metzger wrote: Steven M. Bellovin [EMAIL PROTECTED] writes: There's a technical/philosophical issue lurking here. We tried to solve it in IPsec; not only do I think we didn't succeed, I'm not at all clear we could or should have succeeded. IPsec operates at layer 3, where there are (generally) no user contexts. This makes it difficult to bind IPsec credentials to a user, which means that it inherently can't be as simple to configure as ssh. I disagree. Fundamentally, OpenVPN isn't doing anything IPSEC couldn't do, and yet is is fairly easy to configure. And yet there's no underlying technical reason why it is any easier to configure than IPsec is; it is all a matter of the configuration interface provided by your chosen SSL VPN (in this case, OpenVPN) or IPsec implementation. I find it amusing (but somewhat sad) that in fact one can find basically the same set of flaws in each, but they're considered damning in IPsec while they're handwaved away or overlooked in SSL VPNs. Of course you (Perry) or I can configure either IPsec or OpenVPN in a safe and sane way; and, of course, there are some VPN packages of either type (IPsec or SSL VPN) which have configuration interfaces so bad that we _couldn't_, in fact, set them up safely -- because they prevent safe, sane configuration. The problem is that whether you or I _can_ set software X up safely isn't the question that matters. The question that matters is _will_ a naive user who does not understand the underlying security questions set software X up securely. And, in fact, most VPN software of any type fails this test. My concern is that an excessive focus on how hard is it to set this thing up? can seriously obscure the important second half of the question and if you set it up in the easiest possible way, is it safe? Thor - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: User interface, security, and simplicity
Perry E. Metzger wrote: It is obvious to anyone using modern IPSec implementations that their configuration files are a major source of pain. In spite of this, the designers don't seem to see any problem. The result has been that people see IPSec as unpleasant and write things like OpenVPN when the underlying IPSec protocol is just fine and it is the implementations that are unpleasant. Kerckhoffs' 6th, providing great entertainment for the security world, since 1883. = 6. Finally, it is necessary, given the circumstances that command its application, that the system be easy to use, requiring neither mental strain nor the knowledge of a long series of rules to observe. = iang PS: Although his 6th is arguably the most important, his others are well worth considering: https://www.financialcryptography.com/mt/archives/000195.html - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: User interface, security, and simplicity
Thor Lancelot Simon [EMAIL PROTECTED] writes: On Sat, May 03, 2008 at 07:50:01PM -0400, Perry E. Metzger wrote: I disagree. Fundamentally, OpenVPN isn't doing anything IPSEC couldn't do, and yet is is fairly easy to configure. And yet there's no underlying technical reason why it is any easier to configure than IPsec is; Absolutely. There is no reason one couldn't build an easy to configure IPSec. Indeed, OpenVPN could simply use IPSec if its authors wanted to. No one has created the easy to configure IPSec, however, so I don't use IPSec for my own needs. I find it amusing (but somewhat sad) that in fact one can find basically the same set of flaws in each, but they're considered damning in IPsec while they're handwaved away or overlooked in SSL VPNs. Myself, I don't handwave away said flaws. I don't recommend that clients use OpenVPN, for example. On the other hand, most of my clients can afford to pay admins to spend lots of time on this, and I couldn't afford to spend the time myself. And, in fact, most VPN software of any type fails this test. My concern is that an excessive focus on how hard is it to set this thing up? can seriously obscure the important second half of the question and if you set it up in the easiest possible way, is it safe? Well, it is pretty easy to configure SSH safely. Set it to only use public keys, copy your private key to the remote host in the authorized_keys file, and you're more or less done. There is no reason all the defaults can't be set up for a nice easy to use IPSec based package in such a way that it requires a deliberate effort to make the thing unsafe and it is more or less that easy to use. Unfortunately, people just don't spend nearly the amount of time on the UI for their IPSec systems that they do on the crypto, so they spoil all the hard work they've done making the implementation sound by making it impossible for ordinary people to understand. -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: User interface, security, and simplicity
Thor Lancelot Simon [EMAIL PROTECTED] writes: The upshot is that, indeed, at least as shown here, this particular configuration frontend to OpenVPN is very easy to configure -- if you are willing to settle for much less security than OpenVPN was designed to provide, I think you mean: ]... if you're willing to avoid a huge pile of pointless PKI cruft. which is a major feature of OpenVPN. I am left with the strong suspicion that SSL VPNs are easier to configure and use because a large percentage of their user population simply is not very sensitive to how much security is actually provided. They're easier to configure and use because most users don't want to have to rebuild their entire world around PKI just to set up a tunnel from A to B. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: User interface, security, and simplicity
On Saturday 03 May 2008 14:00, Perry E. Metzger wrote: Right now, to use SSH to remotely connect to a machine using public keys, all I have to do is type ssh-keygen and copy the locally generated public key to a remote machine's authorized keys file. When there is an IPSEC system that is equally easy to use I'll switch to it. OpenBSD has recently added the ipsecctl command, which greatly simplifies setting up IPSEC VPNs, especially between OpenBSD machines. A config file can be as simple as (from the man page): ike esp from 192.168.3.1 to 192.168.3.2 ike esp from 10.1.1.0/24 to 10.1.2.0/24 peer 192.168.3.2 And the file structure for storing certs, public/private keys, and shared secrets (which ipsecctl searches automatically) is equally simple. -- Jeff Simmons [EMAIL PROTECTED] Simmons Consulting - Network Engineering, Administration, Security You guys, I don't hear any noise. Are you sure you're doing it right? -- My Life With The Thrill Kill Kult - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: User interface, security, and simplicity
On Sat, 03 May 2008 17:00:48 -0400 Perry E. Metzger [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Peter Gutmann) writes: I am left with the strong suspicion that SSL VPNs are easier to configure and use because a large percentage of their user population simply is not very sensitive to how much security is actually provided. They're easier to configure and use because most users don't want to have to rebuild their entire world around PKI just to set up a tunnel from A to B. I'm one of those people who uses OpenVPN instead of IPSEC, and I'm one of the people who helped create IPSEC. Right now, to use SSH to remotely connect to a machine using public keys, all I have to do is type ssh-keygen and copy the locally generated public key to a remote machine's authorized keys file. When there is an IPSEC system that is equally easy to use I'll switch to it. Until then, OpenVPN let me get started in about five minutes, and the fact that it is less than completely secure doesn't matter much to me as I'm running SSH under it anyway. There's a technical/philosophical issue lurking here. We tried to solve it in IPsec; not only do I think we didn't succeed, I'm not at all clear we could or should have succeeded. IPsec operates at layer 3, where there are (generally) no user contexts. This makes it difficult to bind IPsec credentials to a user, which means that it inherently can't be as simple to configure as ssh. Put another way, when you tell an sshd whom you wish to log in as, it consults that user's home directory and finds an authorized_keys file. How can IPsec -- or rather, any key management daemon for IPsec -- do that? Per-user SPDs? Is this packet for port 80 for user pat or user chris? I can envision ways around this (especially if we have an IP address per user of a system -- I've been writing about fine-grained IP address assignment for years), but they're inherently a lot more complex than ssh. --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: User interface, security, and simplicity
Thor Lancelot Simon wrote: It's fashionable in some circles (including, it seems, this one) to bash IPsec (particularly IKE) and tout SSL VPNs (particularly OpenVPN) on what are basically user interface grounds. I cannot help repeatedly noting that -- I believe more so than with actual IPsec deployments, whether with or without IKE -- OpenVPN deployments are often configured in hideously insecure ways. This is no more the fault of OpenVPN's designers, of course, than the ghastly configuration interfaces imposed by many IKE impledmentations are the fault of IPsec's designers. We are dropping on end users, sysadmins and nno crypto programmers decisions that seasoned cryptographers tend to screw up, and that end users and sysadmins are never going to comprehend. The way programmers approach modularity and code locality tends to leave the end user outside the cryptographic boundary. The cryptography module is very carefully made entirely independent of the user interface, merely sending up arcane errors from time to time. Consider, for example, the recent cookie stealing security failure in Wordpress, fixed just a few days ago. It seems that for a very long time, there was very straightforward, indeed in retrospect glaringly obvious, security hole that allowed anyone on the internet to take control of any host running Wordpress - which most hosts do run. You can take control from Nigeria, you don't need to tap any lines. Anyone anywhere in the world could have exercised any power over one's server that one's Wordpress application can exercise, which is usually near total power. The defenders of SSL will quite correctly point out that the security hole had absolutely nothing to do with SSL. The hole exists whether one uses SSL or not, and almost no one uses SSL with Wordpress. And that was exactly the problem. The writers of Wordpress, like the writers of every other application, had to handroll their own authentication, and of course fucked up. SSL sessions are not user sessions, thus SSL authentication does not authenticate that user admin is the same entity (or even has the same IP address) as the entity that correctly logged in as user admin, does not, cannot, attempt to provide such authentication, that being a higher layer issue - indeed, SSL authentication is pretty much irrelevant to authenticating anything that the attackers or defenders are likely to care about, which is why user admin on a Wordpress application does not use SSL. SSL is so wonderfully localized that attackers just stroll around it. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
User interface, security, and simplicity
It's fashionable in some circles (including, it seems, this one) to bash IPsec (particularly IKE) and tout SSL VPNs (particularly OpenVPN) on what are basically user interface grounds. I cannot help repeatedly noting that -- I believe more so than with actual IPsec deployments, whether with or without IKE -- OpenVPN deployments are often configured in hideously insecure ways. This is no more the fault of OpenVPN's designers, of course, than the ghastly configuration interfaces imposed by many IKE impledmentations are the fault of IPsec's designers. See, for example, http://doc.pfsense.org/index.php/VPN_Capability_OpenVPN which is the official documentation from the popular pfsense firewall/NAT/VPN package on configuring OpenVPN for use with clients. Of particular note: 1) It is not possible to configure a list of expected identities of users; rather, just a CA which must sign for all users. 2) No CRL is configured, nor do the instructions say to do so, though it is possible. 3) The client and server certificates come from the same CA, and both client and server get configured with *only the CA certificate*, not the subject name of the expected peer. This is, of course, a serious security hole all of its own, since it allows any client to conduct an MITM attack and impersonate the server. 4) Instructions are given for using a package called EasyRSA to set up a CA and create and sign keys. These instructions have several severe flaws of their own: a) They generate client public and private keys *on the CA* rather than using client generation and proper certificate signing requests. This poses a needless risk of private key compromise, which is, in fact, particularly likely, since b) The instructions mention only in passing that oh, by the way, one might want to encrypt the client's new private key, and that one _could_ do so -- but the example does not, in fact, encrypt the key. Anecdotally I have heard of a few users of this combination of software packages (OpenVPN/pfsense/ EasyRSA) who bother to encrypt the private keys they send to users -- but quite a few more who just ship them around plaintext, since the example does so. c) No documentation at all is given of how to revoke a key, nor why one would want to do so. 5) No explanation whatsoever is given of the compromises made in the process of simplifying the configuration of this VPN software -- which are significant and have major security consequences. The upshot is that, indeed, at least as shown here, this particular configuration frontend to OpenVPN is very easy to configure -- if you are willing to settle for much less security than OpenVPN was designed to provide, and much less than, if you're naive about cryptography, you probably think you're getting. Gee, that's funny, that's one of the problems with IPsec implementations that people always cite when they tout SSL VPNs (the other is that some firewalls can't be configured to pass IP protocol 50 for ESP -- but, of course, ESP can be tunneled in UDP, in a standard way, and that's been true for years now). I am left with the strong suspicion that SSL VPNs are easier to configure and use because a large percentage of their user population simply is not very sensitive to how much security is actually provided. Someone said have a firewall, they set up a firewall. Someone says I can't get in through the firewall, set up a VPN, they set up a VPN. For their purposes IP over DNS might serve just as well -- and if enough other people said it was secure, they'd probably get all defensive if you said it wasn't, at least not how they'd configured it. One could think of it, I suppose, as a combination of drinking the Kool Aid and buying the snake oil -- drinking the snake oil? Whatever one calls it one should be very careful of its effects on the popular consciousness when trying to understand what user preferences for this security product over that one actually mean. Thor - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
