> What do you mean... what do I mean by local access? :-) > > I mean local access as in opposite of remote access... as in > physically plugged into the network in question.
I wasn't sure whether you mean access to a local machine or access to a local network segment. > Now if you can fake a cert and have the client use yours > instead of the server's (the whole while the client and REAL > gateway believe YOU are the other) you can easily get at the > payload just as easily as if weren't encrypted? That is the > key and that is easily done without prompting anyone to accept > anything. (and I guess the part you don't believe can be > accomplished?) That's the part we'd discussed earlier at length. Sure, you can give the user another certificate, and the user may well accept the certificate. However, the certificate will not automatically be accepted, because it (a) won't have been signed by any of the trusted root certificates installed on the client, or (b) won't match the hostname to which the user attempted to connect. It's worth pointing out that network administrators can disable the ability of, say, IE to accept unvalidated certificates - tools like Group Policy and IE Administration Kit make this pretty easy. Of course, those don't help much with the rest of the world outside the LAN, but then again, this thread was about intranet security. > You are thinking of vulnerabilities in the make up of > certs/SSL and there aren't any (that I know of) and that > plays into it as well by keeping the client user comfortable > and happy thinking everything is secure. Don't think of > vulnerabilities... think of how well certs and SSL work and > how most people see that httpS:// and they are put at ease > and are content to give you everything you ask for after that. Well, sure, but that's not what you mentioned earlier at all. > Before this conversation, you and anyone else would have > simply accepted a cert prompt from an SSL enabled GMail and > logged in. You definitely wouldn't have had a problem if you > weren't asked to accept the cert. I can't speak for anyone else, but I certainly wouldn't accept an unvalidated cert from a public site. And, I don't have to worry about self-signed certificates on my own tiny little network, because I run a CA. > That most definitely is NOT the real world. I would have to > call that a complete exaggeration. Sure, maybe you've seen > one particular place that secure and that's awesome but > everywhere you go isn't like that or even close. Sorry. My point was simply that there's a lot of variance in the "real world". But for what it's worth, I've seen many places that secure. I should qualify that by mentioning that I work in DC, I guess. Lots of government agencies do that sort of stuff as SOP. And there's a vast gap between what I mentioned and what you mentioned - I'm sure lots of sites fall in between. It's not uncommon to run IDSs and other sorts of internal monitoring tools nowadays - IDS functionality comes bundled with lots of products. > Of course it requires presenting an invalid cert. How else > could it be done? They key is getting the cert accepted > without user interaction. Well, that's kind of a big sticking point. Again, I'm not aware of any open vulnerabilities right now in this area. Again, I'm not a security expert, nor am I a pen tester, so there's a lot of stuff I don't know, but I do try to stay on top of the security lists regularly. > No, I believe you are the only person to bring that up. > It's pretty much been about MiTMA's and reading traffic > and controlling it rather than an actual machine since the > beginning as far as I can tell... There is a certain degree of overlap here, though. To get in the middle in the first place, you often have to do something to convince the client to send traffic to your machine instead of the intended host. And, I've had trouble figuring out exactly what you've been trying to say, so I thought I'd cover all the bases. > Short of a step by step how-to, that's the best I can do for > you. You'll either move on with your life and continue to > think everything is fine and dandy as long as SSL is > implemented 'correctly' and you don't have to hit 'accept' on > a cert prompt or you'll try to raise your network's security > level to the level you mentioned with alarms for > unplugged/plugged in machines. I think I'll move on with my life in either case, thanks for asking. I simply wanted you to point out some piece of evidence in favor of the idea that you can present an invalid certificate and have it accepted automatically. I don't want a step-by-step how-to, just some tiny shred of proof. Because, you see, this is really the key part of the discussion. Any idiot can set up an SSL proxy, and users may well go to that and blindly accept its certificate. And, frankly, I'm willing to live with a little risk. I don't think that, alone, the use of SSL is a security panacea. > I have to wonder though... what happens when you boot up, > shut down or disable/enable a NIC? Is there an alert every > time any of that happens? That would be annoying... Useful... > but annoying lol I don't have anything to do with that, so I honestly don't know. I would guess that the event is logged, but that no alert is raised. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Introducing the Fusion Authority Quarterly Update. 80 pages of hard-hitting, up-to-date ColdFusion information by your peers, delivered to your door four times a year. http://www.fusionauthority.com/quarterly Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:255288 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
