Re: improving ssh
Doesn't this belong on the old SSHv2 WG's mailing list? On Sat, Jul 14, 2007 at 11:43:53AM -0700, Ed Gerck wrote: SSH (OpenSSH) is routinely used in secure access for remote server maintenance. However, as I see it, SSH has a number of security issues that have not been addressed (as far I know), which create unnecessary vulnerabilities. The SSHv2 protocol or OpenSSH (an implementation of SSHv1 and SSHv2)? Some issues could be minimized by turning off password authentication, which is not practical in many cases. Other issues can be addressed by additional means, for example: 1. firewall port-knocking to block scanning and attacks Do you think that implementations of the protocol should implement this? (From what you say below I think your answer is yes. Which brings up the questions why? and how?) 2. firewall logging and IP disabling for repeated attacks (prevent DoS, block dictionary attacks) SSH servers could integrate features like this without needing firewall APIs. 3. pre- and post-filtering to prevent SSH from advertising itself and server OS Unfortunately SSH implementations tend to depend on accurate client and server software version strings in order to work around bugs. Anyways, security by obscurity doesn't help. 4. block empty authentication requests What are those? Are they requests with an empty username? The only SSHv2 userauth methods that support that are the GSS ones, and that's a good feature (it allows the server to derive the username from the client's principal name). 5. block sending host key fingerprint for invalid or no username Currently the only way to do this is to configure SSH servers to support only SSHv2 and only the gss-* key exchange algorithms (see RFC4462, section 2). There exist implementations that support this. To get rid of the host authenticates itself first attitude for all non-GSS-based SSHv2 userauth methods will require radical changes to the protocol and deployment transitions. 6. drop SSH reply (send no response) for invalid or no username The server has to answer with something. Silence is still an answer. So is closing the TCP connection. I believe it would be better to solve them in SSH itself, as one would not have to change the environment in order to further secure SSH. Changing firewall rules, for example, is not always portable and may have unintended consequences. Coding to firewall APIs is even less portable (heck, not all OSes have firewall APIs). Nico -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: improving ssh
On Sat, Jul 14, 2007 at 11:43:53AM -0700, Ed Gerck wrote: SSH (OpenSSH) is routinely used in secure access for remote server maintenance. However, as I see it, SSH has a number of security issues that have not been addressed (as far I know), which create unnecessary vulnerabilities. Some issues could be minimized by turning off password authentication, which is not practical in many cases. Other issues can be addressed by additional means, for example: 1. firewall port-knocking to block scanning and attacks That is, security by obscurity and either adding another dependency (libpcap) or code involving many incompatibilities between systems which OpenSSH portable is ported to (raw sockets interface). I think this can explain why it wasn't included in OpenSSH. 2. firewall logging and IP disabling for repeated attacks (prevent DoS, block dictionary attacks) Actually, this can be done at PAM library level with similar effectiveness and greater simplicity (I did it some time ago as a PoC). Dictionary attacks, however, should be prevented from by forcing users to select strong passwords (appropriate PAM module, again). 3. pre- and post-filtering to prevent SSH from advertising itself and server OS Something like tcpwrappers? I think, this would be pre-filtering. How would you want to do post-filtering? And why not to advertise SSH version? There are as many pros as cons. 4. block empty authentication requests What kind of requests are you talking about? 5. block sending host key fingerprint for invalid or no username 6. drop SSH reply (send no response) for invalid or no username ...so one can easily enumerate existing system users. And you didn't mention about 7. removing subliminal channels in D-H key agreement and IV choosing for CBC and CTR modes. This issue was brought up (for SSH, SSL and IKE/ESP) about year ago in Poland. You know, kleptography is a funny thing. -- Stanislaw Klekot - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: improving ssh
On 7/14/07, Ed Gerck [EMAIL PROTECTED] wrote: 1. firewall port-knocking to block scanning and attacks I would love to see a mode like freenet's silent bob, where connectors must prove probable knowledge of the host key before the node will talk. 5. block sending host key fingerprint for invalid or no username This makes some sense... 1. Client may request proof of host private key. 2. Client must authenticate. 3. Client may request a copy of the host public key. -- Taral [EMAIL PROTECTED] Please let me know if there's any further trouble I can give you. -- Unknown - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: improving ssh
On Jul 14, 2007, at 2:43 PM, Ed Gerck wrote: 1. firewall port-knocking to block scanning and attacks 2. firewall logging and IP disabling for repeated attacks (prevent DoS, block dictionary attacks) 3. pre- and post-filtering to prevent SSH from advertising itself and server OS 4. block empty authentication requests 5. block sending host key fingerprint for invalid or no username 6. drop SSH reply (send no response) for invalid or no username None of these are crypto issues. The OpenSSH dev list (http:// www.openssh.com/list.html) would almost certainly lend itself to a more productive discussion of these concerns. Cheers, -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: improving ssh
Ivan Krstić wrote: On Jul 14, 2007, at 2:43 PM, Ed Gerck wrote: 1. firewall port-knocking to block scanning and attacks 2. firewall logging and IP disabling for repeated attacks (prevent DoS, block dictionary attacks) 3. pre- and post-filtering to prevent SSH from advertising itself and server OS 4. block empty authentication requests 5. block sending host key fingerprint for invalid or no username 6. drop SSH reply (send no response) for invalid or no username None of these are crypto issues. Perhaps not the way they are solved today (see above), and that IS the problem. For example, the lack of good crypto solutions to protocol bootstrap contributes significantly to security holes 1-7. Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: improving ssh
i'm an OpenBSD developer, so i have some knowlege but could be biased. SSH (OpenSSH) is routinely used in secure access for remote server maintenance. However, as I see it, SSH has a number of security issues that have not been addressed (as far I know), which create unnecessary vulnerabilities. Some issues could be minimized by turning off password authentication, which is not practical in many cases. Other issues can be addressed by additional means, for example: 1. firewall port-knocking to block scanning and attacks 2. firewall logging and IP disabling for repeated attacks (prevent DoS, block dictionary attacks) i guess it can be handled in lines of spamd (greylisting) on OpenBSD. 3. pre- and post-filtering to prevent SSH from advertising itself and server OS is there any point in this as you can fingerprint OS both actively (nmap) and passively (p0f)? 4. block empty authentication requests 5. block sending host key fingerprint for invalid or no username 6. drop SSH reply (send no response) for invalid or no username i can understand your desire, but this is a feature used by some of the anonymous services such as anonymous CVS. i'd leave it to openssh developers. itojun - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: How the Greek cellphone network was tapped.
Leichter, Jerry [EMAIL PROTECTED] writes: Between encrypted VOIP over WIFI and eventually over broadband cell - keeping people from running voice over their broadband connections is a battle the telco's can't win in the long run - and just plain encrypted cell phone calls, I think in a couple of years anyone who wants secure phone connections will have them. I think you're looking at this a bit wrong. I rememeber the same opinion as the above being expressed on the brew-a-stu list about fifteen years ago, and no doubt some other list will carry it in another fifteen years time, with nothing else having changed. Anyone who wants secure voice connections (governments/military and a vanishingly small number of hardcore geeks) already have them, and have had them for years. Everyone else just doesn't care, and probably never will. This is why every single encrypted-phones-for- the-masses project has failed in the market. People don't see phone eavesdropping as a threat, and therefore any product that has a nonzero price difference or nonzero usability difference over an unencrypted one will fail. This is why the only successful encrypted phone to date has been Skype, because the crypto comes for free. I once had a chat with someone who was responsible for indoctrinating the newbies that turn up in government after each election into things like phone security practices. He told me that after a full day of drilling it into them (well, alongside a lot of other stuff from other departments) it sometimes took them as long as a week before they were back to loudly discussing sensitive information on a cellphone in the middle of a crowded restaurant. So in terms of secure voice communications, the military and geeks are already well served, and everyone else doesn't care. Next, please. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: How the Greek cellphone network was tapped.
[EMAIL PROTECTED] (Peter Gutmann) writes: I think you're looking at this a bit wrong. I rememeber the same opinion as the above being expressed on the brew-a-stu list about fifteen years ago, and no doubt some other list will carry it in another fifteen years time, with nothing else having changed. Anyone who wants secure voice connections (governments/military and a vanishingly small number of hardcore geeks) already have them, and have had them for years. Everyone else just doesn't care, and probably never will. I think this is a slight overstatement. If security on login connections was expensive, difficult, or not part of the common infrastructure, everyone would still be using plaintext passwords over telnet. However, ssh is just as easy or in fact easier to use then telnet/ftp/etc., so that it has become ubiquitous. If using secure phones was as cheap and easy as using insecure ones, everyone would do it. They just won't go out of their way to do it. The market will happily accept a new feature that is free and zero complexity in use. It is well within technical possibility to create such a thing -- the issue is purely political. Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: How the Greek cellphone network was tapped.
| Between encrypted VOIP over WIFI and eventually over broadband cell - | keeping people from running voice over their broadband connections is | a battle the telco's can't win in the long run - and just plain | encrypted cell phone calls, I think in a couple of years anyone who | wants secure phone connections will have them. | | I think you're looking at this a bit wrong. I rememeber the same | opinion as the above being expressed on the brew-a-stu list about | fifteen years ago, and no doubt some other list will carry it in | another fifteen years time, with nothing else having changed. Anyone | who wants secure voice connections (governments/military and a | vanishingly small number of hardcore geeks) already have them, and | have had them for years. Everyone else just doesn't care, and | probably never will. This is why every single encrypted-phones-for- | the-masses project has failed in the market. People don't see phone | eavesdropping as a threat, and therefore any product that has a | nonzero price difference or nonzero usability difference over an | unencrypted one will fail. This is why the only successful encrypted | phone to date has been Skype, because the crypto comes for free. | | I once had a chat with someone who was responsible for indoctrinating | the newbies that turn up in government after each election into things | like phone security practices. He told me that after a full day of | drilling it into them (well, alongside a lot of other stuff from other | departments) it sometimes took them as long as a week before they were | back to loudly discussing sensitive information on a cellphone in the | middle of a crowded restaurant. | | So in terms of secure voice communications, the military and geeks are | already well served, and everyone else doesn't care. Next, please. I won't disagree with you here. Most people don't perceive voice monitoring as a threat to them - and if you're talking about monitoring by many governments and by business intelligence snoopers, they are perfectly correct. (I say many governments because those governments that actively monitor and control large portions of their citizenry hardly make a secret of that fact, and citizens of those countries just assume they might be overheard and act accordingly. The citizens of, for lack of a better general phrase, the Western democracies, are quite right in their assessment that their governments really don't care about what they are saying on the phone, unless they are part of a very small subpopulation involved, whether legitimately or otherwise, in politics or intelligence or a couple of other pretty well understood areas.) Selling protection against voice snooping to most people under current circumstances is like selling flood insurance to people living in the desert. If you're an insurance hacker - like a security hacker - you can point out that flash floods *can* happen, but if they are so rare that no one is likely to be affected in their lifetime, your sales pitch *should* fail. What will change things is not the technology but the perception of a threat. Forty years ago, the perceived threat from airplane hijacking was that it was non-existent, and no one would consider paying the cost. Today, we play a very significant cost. The threat is certainly greater, but the *perceived* threat is orders of magnitude beyond even that. The moment the perceived threat from phone eavesdropping exceeds some critical level, the market for solutions (good and, of course, worthless) will materialize. As you note, in the military and intelligence community, the real and perceived threats have been there for years. And the crypto hackers will perceive a threat whether it exists or not. I'd guess that the next step will be in the business community. All it will take is one case where a deal is visibly lost because of proven eavesdropping (proven in quotes because it's unlikely that there will really be any proof - just a *perception* of a smoking gun - and in fact it could well be that the trigger case will really be someone covering his ass over a loss for entirely different reasons) and all of a sudden there will be a demand for strong crypto on every Blackberry phone link. Things have a way of spreading from there: If the CEO's need this, then maybe I need it, too. If it is expensive or inconvenient, I may feel the need, but I won't act on it. But the CEO's will ensure that it isn't inconvenient - they won't put up with anything that isn't invisible to them - and technology will quickly drive down the cost. -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: How the Greek cellphone network was tapped.
At 07:37 AM 7/12/2007, Eric Cronin wrote: With current CPUs and audio codecs you can get decent voice quality over 9600bps. Yes and no. There are lots of 8kbps codecs, and some 6.5 and 5.3kbps codecs, all off which give acceptable voice quality if transmission's ok. (And you can reduce average transmission rates by 40-50% with silence suppression.) However, that's the raw codec rate - if you're taking the VOIP packets, wrapping them in RTP, UDP, and IP headers, and then transmitting them on a layer 2 protocol with as little overhead as PPP or Frame, the 8kbps becomes more like 26 kbps (Ethernet and ATM are worse, and DSL is ATM underneath - I'm not sure what the cellular carriers do for framing.) The problem is that the Voice-stream data packets are extremely small - the same headers don't add much overhead percentage when you're using 1500-byte data packets. In some environments you can do header compression to save about half the bandwidth, but in general you can't. The Asterisk IP PBX has a trunking protocol that lets you use one set of RTP/UDP/IP headers to carry multiple streams of voice packets, so you can connect two locations together for close to the raw protocol speeds, but that's not likely to apply to a mobile phone situation. The other way to avoid the VOIP overhead is to use one of the old voice-over-data designs that uses point-to-point async or sync connections without an IP layer (e.g. raw modems.) That lets you send voice for much closer to the 9600 bps (depending on sync protocol, async stop-bits, etc.) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
quantum random number generator ...
hmm http://qrbg.irb.hr/ -- mike http://lets.coozi.com.au/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
ADMIN: SSH discussion shut down
The SSH discussion has (in messages I didn't forward) rapidly degenerated into an argument that isn't very high signal. I'd suggest that the non-crypto aspects are best discussed on other mailing lists like the IETF SSH working group lists and the OpenSSH developers mailing list. If there are specific cryptographic flaws in the protocol, I'd say they are fair game if the discussion is clear, brief and dispassionate. -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Enigma for sale on eBay
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItemitem=270146164488 -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: improving ssh
Ed Gerck [EMAIL PROTECTED] writes: Some issues could be minimized by turning off password authentication, which is not practical in many cases. That would probably make things much worse. A study of SSH attacks a few years ago showed that nearly two thirds of all SSH private keys were stored on disk with no protection at all, so that simply being able to read a hard drive will get you access to any number of systems without having to trojan the SSH client or plant a keyboard logger as you'd need for an SSH password. So turning off password auth would make things less secure, not more. 1. firewall port-knocking to block scanning and attacks 2. firewall logging and IP disabling for repeated attacks (prevent DoS, block dictionary attacks) I started work on an paper that looked at doing exactly this based on traces from SSH scanning attacks a year or two back, and realised that this is an arms race that you can't win. No matter what heuristics you use, all an attacker has to do is change their scanning pattern to avoid them and all your work is rendered useless. The reason I never finished the paper (well, apart from that fact that this type of defence is a lost cause) is because there's a much easier way to do this than at the firewall or network level. There's a paper by Pinkas and Sander, Securing Passwords Against Dictionary Attacks, later updated by van Oorschot in a TISSEC paper (sorry, don't have the ref.handy) that contains a very nice, elegant way to defeat SSH (and, in general, any password-based protocol) scanning attacks. I have an RFC draft to add this to SSH on the back burner, I just haven't finished it yet because (a) too many other things to do and (b) I'm not sure how it'll be received by the SSH community, who seem to see public-key auth as the answer to any problem. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: How the Greek cellphone network was tapped.
On Tue, 17 Jul 2007 13:11:41 -0400 (EDT) Leichter, Jerry [EMAIL PROTECTED] wrote: I'd guess that the next step will be in the business community. All it will take is one case where a deal is visibly lost because of proven eavesdropping (proven in quotes because it's unlikely that there will really be any proof - just a *perception* of a smoking gun - and in fact it could well be that the trigger case will really be someone covering his ass over a loss for entirely different reasons) and all of a sudden there will be a demand for strong crypto on every Blackberry phone link. Things have a way of spreading from there: If the CEO's need this, then maybe I need it, too. If it is expensive or inconvenient, I may feel the need, but I won't act on it. But the CEO's will ensure that it isn't inconvenient - they won't put up with anything that isn't invisible to them - and technology will quickly drive down the cost. You're an optimist. There was the Israeli case of the tailored virus. I haven't noticed any rush to get rid of insecure operating systems, mailers, and word processors. Or have a look at http://fe24.news.re3.yahoo.com/s/nm/20070717/tc_nm/internet_attack_dc and ask if that will do it. (Department of Transportation? Department of Defenses, more likely, from that list of businesses...) Today's Wall Street Journal reported on new threats from ads on the Internet, and loudly worried why ad companies and web sites weren't doing more to filter their offerings. But an ad is just web content, which means that the real problem is the web browser and host OS. Will that prompt a switch? We're talking about phone calls -- did all of the well-publicized cellular eavesdropping (Prince Charles, Newt Gingrich (then a major US politician), and more) prompt a change? Well, there are now US laws against that sort of phone eavesdropping gear -- a big help Want another example? How many US corporations have major operations in China? What are the odds that the Chinese government is listening in? If you're uncertain, see (a) the posting on this list a few days ago about the landing declaration about communications security devices and yesterday's news story about email problems to China because of apparent problems with the Great Firewall (http://www.cnn.com/2007/TECH/07/18/china.email.reut/index.html). None of his seems to have affected business there. (Nor are corporations unaware of this; I was advising people on this close to 20 years ago.) I agree that it will take a trigger. I don't know what that trigger will be, but it won't be something as simple as a proven case. It's hard to predict what will get enough people upset; sometimes, it's nothing at all. (Remember the Pentium serial number case? Objectively, that was a complete non-issue, but enough people got upset about it that Intel had to back off.) It will also have to be dead simple. It can't happen on the POTS network, because modem handshaking takes too long. It can't happen on conventional cellular unless the voice is traveling over a clear-channel end-to-end data connection, not something that the carrier's equipment knows is voice. (There's also the question of phone CPU access to the voice channel, per Bill Stewart's post.) It could happen for VoIP if done properly, as others have pointed out. It has to be easy to use, which means that things like PKIs are, shall we say, obstacles. --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: New article on root certificate problems with Windows
Paul Hoffman [EMAIL PROTECTED] writes: I posted a new security research article at http://www.proper.com/root-cert-problem/. It is not directly related to crypto (although not so much of the traffic on this list is...), it does relate to some PKI topics that are favorites of this list. The executive summary, so I've got something to reply to: In the default configuration for Windows XP with Service Pack 2 (SP2), if a user removes one of the trusted root certificates, and the certifier who issued that root certificate is trusted by Microsoft, Windows will silently add the root certificate back into the user's store and use the original trust settings. While I don't agree with this behaviour, I can see why Microsoft would do this, and I can't see them changing it at any time in the future. It's the same reason why they ignore key usage restrictions and allow (for example) an encryption-only key to be used for signatures, and a thousand other breaches of PKI etiquette: There'd be too many user complaints if they didn't. The people designing this stuff aren't the ones who have to man the tech helpdesk when users find that things break because of some action that they don't even understand (see e.g. the Xerox PARC study where a bunch of people with PhDs in computer science, after following paint-by-numbers instructions to install certs on their machines, had absolutely no idea what they'd just done to their computers). From a security point of view, this is really bad. From a usability point of view, it's necessary. The solution is to let the HCI people into the design process, something that's very rarely, if ever, done in the security field [0]. Peter. [0] Before people jump up and down about this: Yes, HCISec has become a very active and productive field in the last few years. Unfortunately far too little of the work that's being done is making it into products though. We have lots of data saying X is unusable in practice and The best way to handle this is Y, but developers keep on pushing X and avoiding (or don't even know about) Y. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: New article on root certificate problems with Windows
At 2:45 AM +1200 7/20/07, [EMAIL PROTECTED] wrote: From a security point of view, this is really bad. From a usability point of view, it's necessary. As you can see from my list of proposed solutions, I disagree. I see no reason not to to alert a user *who has removed a root* that you are about to put it back in. Note that I did not criticize the practice of starting with a zillion roots that Microsoft trusts. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: New article on root certificate problems with Windows
[EMAIL PROTECTED] wrote: From a security point of view, this is really bad. From a usability point of view, it's necessary. I agree with all the above, including deleted. The solution is to let the HCI people into the design process, something that's very rarely, if ever, done in the security field [0]. To jump up and down ... if that was the solution, it would have been done by now :) I would instead state that the solution was whatever Skype and SSH did. And the opposite of whatever IPSec, SSL, Clipper, S/MIME, DRM, and all the other failures did. HCI was one of the things, but others were as important: lack of open critique, service-before-security, crypto-for-free, total solution, narrow problem, etc. iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: How the Greek cellphone network was tapped.
An earlier post, talking about vulnerabilities and the lack of an appropriate market response, said: We're talking about phone calls -- did all of the well-publicized cellular eavesdropping (Prince Charles, Newt Gingrich (then a major US politician), and more) prompt a change? Well, there are now US laws against that sort of phone eavesdropping gear -- a big help I think the most publicized cases of cellular interception, including the two mentioned above, were interceptions of analog calls. Such interception was not too hard to do. In some cases you could pick up one side of such calls on old American TV sets (sets that tuned above channel 69 on the UHF dial). Much better interception equipment was still pretty simple. I understand that there was sometimes enough talker echo that, if you listened on the base-to-mobile link you could understand both sides of the call-you didn't even need two receivers. However, interception of digital wireless signals requires more skill and expense. Interception of CDMA is harder than interception of GSM. Interception and recovery of encrypted digital is still more difficult. The 3G wireless standards permit AES quality encryption of the voice-I don't know if carriers have this turned on. I am pretty sure they have it or the equivalent turned on for functions that limit theft of service such as the initial activation of service on CDMA networks. I do know of business executives who, when informed of the ease of interception of analog cellular, changed their behavior. Chuck Jackson - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Yahoo + iPhone = replay attacks
A blog entry which claims that the proprietary Push IMAP protocol that Apple and Yahoo came up with is deeply flawed -- the entry states that the entire thing is vulnerable to trivial replay attacks. http://blog.dave.cridland.net/?p=32 Hat tip: Marshall Rose If true, this is yet more evidence for the ancient hypothesis that it is foolish to roll your own security protocols. Perry -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: New article on root certificate problems with Windows
[EMAIL PROTECTED] wrote: The executive summary, so I've got something to reply to: In the default configuration for Windows XP with Service Pack 2 (SP2), if a user removes one of the trusted root certificates, and the certifier who issued that root certificate is trusted by Microsoft, Windows will silently add the root certificate back into the user's store and use the original trust settings. While I don't agree with this behaviour, I can see why Microsoft would do this, and I can't see them changing it at any time in the future. It's the same reason why they ignore key usage restrictions and allow (for example) an encryption-only key to be used for signatures, and a thousand other breaches of PKI etiquette: There'd be too many user complaints if they didn't. The real flaw that I see in their design is that they permit certificates that they installed to be removed. Instead they should have provided a disabled feature so that those who wish to disable installed certs can do so and thereby ensure that in the future they won't be restored. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
summary, Re: improving ssh
List, Thanks everyone for the feedback. There are now some ideas how things could be improved using crypto. I prepared a summary of the public and private responses, and clarifications, at: http://email-security.blogspot.com/2007_07_01_archive.html Comments are welcome in here (if crypto) an in the blog in general. Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
