Re: Break it down for n00bs: security problems of non-SSL intrane t?
On Thursday 05 October 2006 18:49, Kevin Aebig wrote: Maybe I'm a bit naïve in this department, but isn't the following pretty well fact: 1 - MitM attacks were initially born from Wireless Network Hacking, not on location. Geez, Err, no ? See, for instance, the US navy fitting subs out with magnetic induction kit and parking them over undersea cables, never mind just tapping the telegraph lines at the entry points to the US during both world wars. 2 - A good business based Switch or Firewall, properly configured can and will prevent / alert against most inhouse hacks / exploits. Nope. For instance, I can install a rougue DHCP server that responds faster than the real one, and redirect all your traffic via me. 3 - The skills needed to pull a hack of this sort would basically mean that at one point your company hired a professional security expert, thus opening the door anyways? Err, what ? Are you saying all security professionals are corrupt ? Or that it can't be pulled off by a spotty 13 year old kid ? 99.% of computer users wouldn't know where to start when it comes to hacking SSL. They don't understand the client / server communication nor do they understand the encryption algorithms. This is true though. I've personally got a couple security guys I use to handle audits for my clients and though they have ways of pulling this off, it's extremely difficult... and it's all they do. Pfft. -- Tom Chiverton Helping to administratively enable best-of-breed materials This email is sent for and on behalf of Halliwells LLP. Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at St James's Court Brown Street Manchester M2 2JF. A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by the Law Society. CONFIDENTIALITY This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 8008. For more information about Halliwells LLP visit www.halliwells.com. ~| 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:255771 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
Re: Break it down for n00bs: security problems of non-SSL intrane t?
On Wednesday 04 October 2006 17:24, Bobby Hartsfield wrote: You wouldnt inspect or rewrite anything more than a router would. All you have to do is adjust the headers (just like the router does) for local traffic then send the packets out the NIC that you are monitoring. Ethereal, Ettercap or whatever monitor you are using reads the rest of the packet. You are describing evesdropping, which isn't a MitM attack as such. 'ettercap' is misspelled and wants to correct it with 'Ethereal' DYM Wireshark :-) -- Tom Chiverton Helping to authoritatively scale magnetic e-markets This email is sent for and on behalf of Halliwells LLP. Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at St James's Court Brown Street Manchester M2 2JF. A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by the Law Society. CONFIDENTIALITY This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 8008. For more information about Halliwells LLP visit www.halliwells.com. ~| 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:255615 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
RE: Break it down for n00bs: security problems of non-SSL intrane t?
Eavesdropping is simply reading the packets on the network meant for someone else. A MitM is an extension of that since you don't simply listen and read packets, you play a huge role in directing the traffic as well. If you really WANTED to rewrite data in the payload of the packets and change what the endpoints see or don't see I don't see any reason why you couldn't. You would have to set up a proxy such as squid like you mentioned in order to do so but... without proxy software and capabilities, I still don't see how the computer that the attack originates from could be considered a proxy more so than a router. DYM Wireshark :-) No, but that would have been funnier ;-P -Original Message- From: Tom Chiverton [mailto:[EMAIL PROTECTED] Sent: Thursday, October 05, 2006 4:24 AM To: CF-Talk Subject: Re: Break it down for n00bs: security problems of non-SSL intrane t? On Wednesday 04 October 2006 17:24, Bobby Hartsfield wrote: You wouldnt inspect or rewrite anything more than a router would. All you have to do is adjust the headers (just like the router does) for local traffic then send the packets out the NIC that you are monitoring. Ethereal, Ettercap or whatever monitor you are using reads the rest of the packet. You are describing evesdropping, which isn't a MitM attack as such. 'ettercap' is misspelled and wants to correct it with 'Ethereal' DYM Wireshark :-) -- Tom Chiverton Helping to authoritatively scale magnetic e-markets This email is sent for and on behalf of Halliwells LLP. Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at St James's Court Brown Street Manchester M2 2JF. A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by the Law Society. CONFIDENTIALITY This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 8008. For more information about Halliwells LLP visit www.halliwells.com. ~| 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:255635 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: Break it down for n00bs: security problems of non-SSL intrane t?
On Thursday 05 October 2006 13:57, Bobby Hartsfield wrote: , I still don't see how the computer that the attack originates from could be considered a proxy more so than a router Because routers do not change the body of packets. -- Tom Chiverton Helping to biannually deploy end-to-end interfaces This email is sent for and on behalf of Halliwells LLP. Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at St James's Court Brown Street Manchester M2 2JF. A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by the Law Society. CONFIDENTIALITY This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 8008. For more information about Halliwells LLP visit www.halliwells.com. ~| 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:255648 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
RE: Break it down for n00bs: security problems of non-SSL intrane t?
Why does the modification of payload keep coming up? Again... I never said anything about changing the body of packets and there is no need to do so just to perform a mitm to READ data. Before someone responds to that with then there is no need to perform a complete mitm to simply READ data either there is when SSL is involved. -Original Message- From: Tom Chiverton [mailto:[EMAIL PROTECTED] Sent: Thursday, October 05, 2006 9:13 AM To: CF-Talk Subject: Re: Break it down for n00bs: security problems of non-SSL intrane t? On Thursday 05 October 2006 13:57, Bobby Hartsfield wrote: , I still don't see how the computer that the attack originates from could be considered a proxy more so than a router Because routers do not change the body of packets. -- Tom Chiverton Helping to biannually deploy end-to-end interfaces This email is sent for and on behalf of Halliwells LLP. Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at St James's Court Brown Street Manchester M2 2JF. A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by the Law Society. CONFIDENTIALITY This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 8008. For more information about Halliwells LLP visit www.halliwells.com. ~| 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:255655 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: Break it down for n00bs: security problems of non-SSL intrane t?
On Thursday 05 October 2006 14:38, Bobby Hartsfield wrote: Why does the modification of payload keep coming up? Because that's what makes something a proxy and not a router, and you said '[I can't] see how the computer that the attack originates from could be considered a proxy more so than a router'. Modifying the packets is the how. -- Tom Chiverton Helping to adaptively brand ubiquitous content This email is sent for and on behalf of Halliwells LLP. Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at St James's Court Brown Street Manchester M2 2JF. A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by the Law Society. CONFIDENTIALITY This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 8008. For more information about Halliwells LLP visit www.halliwells.com. ~| 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:255657 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Break it down for n00bs: security problems of non-SSL intrane t?
Because that's what makes something a proxy and not a router Ok, I think I've made it clear that a mitm does not have to modify payloads in order to be successful so with that still in mind (since I've hammered that point into the ground thus far)... if, by your own definition, modifying packet payload is a (the) characteristic that would turn a normal router into a proxy, why would you support the theory that the machine that a mitm originates from is anything like a proxy -or- that it is more so like a proxy than a router? -Original Message- From: Tom Chiverton [mailto:[EMAIL PROTECTED] Sent: Thursday, October 05, 2006 9:55 AM To: CF-Talk Subject: Re: Break it down for n00bs: security problems of non-SSL intrane t? On Thursday 05 October 2006 14:38, Bobby Hartsfield wrote: Why does the modification of payload keep coming up? Because that's what makes something a proxy and not a router, and you said '[I can't] see how the computer that the attack originates from could be considered a proxy more so than a router'. Modifying the packets is the how. -- Tom Chiverton Helping to adaptively brand ubiquitous content This email is sent for and on behalf of Halliwells LLP. Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at St James's Court Brown Street Manchester M2 2JF. A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by the Law Society. CONFIDENTIALITY This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 8008. For more information about Halliwells LLP visit www.halliwells.com. ~| 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:255676 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: Break it down for n00bs: security problems of non-SSL intrane t?
On Thursday 05 October 2006 16:29, Bobby Hartsfield wrote: router into a proxy, why would you support the theory that the machine that a mitm originates from is anything like a proxy In the sense it intercepts traffic, it is. Anyways. I think we're arguing from the same sides of the street, as well as being wy of topic. -- Tom Chiverton Helping to preemptively envisioneer innovative designs This email is sent for and on behalf of Halliwells LLP. Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at St James's Court Brown Street Manchester M2 2JF. A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by the Law Society. CONFIDENTIALITY This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 8008. For more information about Halliwells LLP visit www.halliwells.com. ~| 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:255680 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Break it down for n00bs: security problems of non-SSL intrane t?
Ok, I think I've made it clear that a mitm does not have to modify payloads in order to be successful ... Wouldn't the payloads need to be modified, if they're encrypted using SSL? If you trick the client into talking to your machine instead of the intended host, and you present a certificate that isn't identical to the intended host's certificate, you would need to decrypt the content with your certificate. You'd then have to encrypt that content with the intended host's certificate. While the actual data you're interested in reading will not have changed, the information in the packet you received from the client will not be the same as the information in the one you send to the intended host, right? That seems to me to be the behavior of a proxy, not a router. Routers rewrite transport layer stuff, but you'd need to rewrite application layer stuff (I think those are the two relevent OSI layers, but I'm too lazy to check). And, I'm not trying to upset you or anything. I'm genuinely interested in figuring this out. You mentioned previously that it would be possible to either use the intended host's certificate or present a certificate of your own that doesn't trigger a warning message on the client. Did I understand you correctly? If so, can you point to anything about that at all? If not, I apologize for misinterpreting you. Thanks! 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:255689 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Break it down for n00bs: security problems of non-SSL intrane t?
Maybe I'm a bit naïve in this department, but isn't the following pretty well fact: 1 - MitM attacks were initially born from Wireless Network Hacking, not on location. 2 - A good business based Switch or Firewall, properly configured can and will prevent / alert against most inhouse hacks / exploits. 3 - The skills needed to pull a hack of this sort would basically mean that at one point your company hired a professional security expert, thus opening the door anyways? 99.% of computer users wouldn't know where to start when it comes to hacking SSL. They don't understand the client / server communication nor do they understand the encryption algorithms. I've personally got a couple security guys I use to handle audits for my clients and though they have ways of pulling this off, it's extremely difficult... and it's all they do. !k -Original Message- From: Dave Watts [mailto:[EMAIL PROTECTED] Sent: Thursday, October 05, 2006 11:13 AM To: CF-Talk Subject: RE: Break it down for n00bs: security problems of non-SSL intrane t? Ok, I think I've made it clear that a mitm does not have to modify payloads in order to be successful ... Wouldn't the payloads need to be modified, if they're encrypted using SSL? If you trick the client into talking to your machine instead of the intended host, and you present a certificate that isn't identical to the intended host's certificate, you would need to decrypt the content with your certificate. You'd then have to encrypt that content with the intended host's certificate. While the actual data you're interested in reading will not have changed, the information in the packet you received from the client will not be the same as the information in the one you send to the intended host, right? That seems to me to be the behavior of a proxy, not a router. Routers rewrite transport layer stuff, but you'd need to rewrite application layer stuff (I think those are the two relevent OSI layers, but I'm too lazy to check). And, I'm not trying to upset you or anything. I'm genuinely interested in figuring this out. You mentioned previously that it would be possible to either use the intended host's certificate or present a certificate of your own that doesn't trigger a warning message on the client. Did I understand you correctly? If so, can you point to anything about that at all? If not, I apologize for misinterpreting you. Thanks! 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:255690 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Break it down for n00bs: security problems of non-SSL intrane t?
These attacks are pretty difficult. They are not born from Wireless Nework Hacking, but have existed for years, and have their roots in the wired networks. Switches don't always prevent these attacks. Although a switch should separate where the data goes and makes sniffing harder, it's a little known fact that most switches have a firehose mode, which is when you overload the switch with too much data, it just starts acting like a hub. The biggest thing in the Man in the Middle attack is to trick the client to think that you are the server. This is usually done with either DNS poisoning or ARP poisoning. ARP poisoning can only be done on the local network, and basically you are telling the clients that you are the router, and to send all packets to you. DNS poisoning I think can only be done by getting access to the real dns server or tricking the client somehow to use you as the DNS server. Modifying the hosts file can work as well. (Note that it may be possible to poison local network WINS or Lanman (not sure what the correct term is) name resolution. I'm not exactly sure what point #3 is saying. You dont need to have hired a security expert in order for a hacker to get into your network and wreak havoc. I might be misunderstanding you though. Russ -Original Message- From: Kevin Aebig [mailto:[EMAIL PROTECTED] Sent: Thursday, October 05, 2006 1:49 PM To: CF-Talk Subject: RE: Break it down for n00bs: security problems of non-SSL intrane t? Maybe I'm a bit naïve in this department, but isn't the following pretty well fact: 1 - MitM attacks were initially born from Wireless Network Hacking, not on location. 2 - A good business based Switch or Firewall, properly configured can and will prevent / alert against most inhouse hacks / exploits. 3 - The skills needed to pull a hack of this sort would basically mean that at one point your company hired a professional security expert, thus opening the door anyways? 99.% of computer users wouldn't know where to start when it comes to hacking SSL. They don't understand the client / server communication nor do they understand the encryption algorithms. I've personally got a couple security guys I use to handle audits for my clients and though they have ways of pulling this off, it's extremely difficult... and it's all they do. !k -Original Message- From: Dave Watts [mailto:[EMAIL PROTECTED] Sent: Thursday, October 05, 2006 11:13 AM To: CF-Talk Subject: RE: Break it down for n00bs: security problems of non-SSL intrane t? Ok, I think I've made it clear that a mitm does not have to modify payloads in order to be successful ... Wouldn't the payloads need to be modified, if they're encrypted using SSL? If you trick the client into talking to your machine instead of the intended host, and you present a certificate that isn't identical to the intended host's certificate, you would need to decrypt the content with your certificate. You'd then have to encrypt that content with the intended host's certificate. While the actual data you're interested in reading will not have changed, the information in the packet you received from the client will not be the same as the information in the one you send to the intended host, right? That seems to me to be the behavior of a proxy, not a router. Routers rewrite transport layer stuff, but you'd need to rewrite application layer stuff (I think those are the two relevent OSI layers, but I'm too lazy to check). And, I'm not trying to upset you or anything. I'm genuinely interested in figuring this out. You mentioned previously that it would be possible to either use the intended host's certificate or present a certificate of your own that doesn't trigger a warning message on the client. Did I understand you correctly? If so, can you point to anything about that at all? If not, I apologize for misinterpreting you. Thanks! 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:255704 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
RE: Break it down for n00bs: security problems of non-SSL intrane t?
Maybe I'm a bit naïve in this department, but isn't the following pretty well fact: 1 - MitM attacks were initially born from Wireless Network Hacking, not on location. I don't know the origin of the first mitm but I would have to think it was before wireless was main stream. 2 - A good business based Switch or Firewall, properly configured can and will prevent / alert against most inhouse hacks / exploits. I've yet to see one that secure from inside attacks 3 - The skills needed to pull a hack of this sort would basically mean that at one point your company hired a professional security expert, thus opening the door anyways? Not at all. Not counting your choice of packet monitor, in Linux, a basic mitm can be accomplished with 3 simple commands all found in one package. In windows, again, minus your choice of packet monitor, the simplest method that I can think of is already scripted in one application and a couple of clicks are all it takes The only bits of information you need to know before hand are A) Which clients you plan to sniff B) Which IP address is the gateway Those are not what I'd call extremely difficult to figure out and by no means would it require a professional security expert. Chances are that if you are on the network already, you probably know that info but if you don't, mapping a network from within is very easy to do on most networks. Tom and I have taken this discussion with off the list to avoid the inevitable screaming pointed in our direction about being so off topic (which is S rightfully deserved). Feel free to email me off list about this response if you'd like but I'm going to TRY my best to keep from replying to anymore posts about it on the list. (Who am I kidding though... I have no will power lol) -Original Message- From: Kevin Aebig [mailto:[EMAIL PROTECTED] Sent: Thursday, October 05, 2006 1:49 PM To: CF-Talk Subject: RE: Break it down for n00bs: security problems of non-SSL intrane t? Maybe I'm a bit naïve in this department, but isn't the following pretty well fact: 1 - MitM attacks were initially born from Wireless Network Hacking, not on location. 2 - A good business based Switch or Firewall, properly configured can and will prevent / alert against most inhouse hacks / exploits. 3 - The skills needed to pull a hack of this sort would basically mean that at one point your company hired a professional security expert, thus opening the door anyways? 99.% of computer users wouldn't know where to start when it comes to hacking SSL. They don't understand the client / server communication nor do they understand the encryption algorithms. I've personally got a couple security guys I use to handle audits for my clients and though they have ways of pulling this off, it's extremely difficult... and it's all they do. !k -Original Message- From: Dave Watts [mailto:[EMAIL PROTECTED] Sent: Thursday, October 05, 2006 11:13 AM To: CF-Talk Subject: RE: Break it down for n00bs: security problems of non-SSL intrane t? Ok, I think I've made it clear that a mitm does not have to modify payloads in order to be successful ... Wouldn't the payloads need to be modified, if they're encrypted using SSL? If you trick the client into talking to your machine instead of the intended host, and you present a certificate that isn't identical to the intended host's certificate, you would need to decrypt the content with your certificate. You'd then have to encrypt that content with the intended host's certificate. While the actual data you're interested in reading will not have changed, the information in the packet you received from the client will not be the same as the information in the one you send to the intended host, right? That seems to me to be the behavior of a proxy, not a router. Routers rewrite transport layer stuff, but you'd need to rewrite application layer stuff (I think those are the two relevent OSI layers, but I'm too lazy to check). And, I'm not trying to upset you or anything. I'm genuinely interested in figuring this out. You mentioned previously that it would be possible to either use the intended host's certificate or present a certificate of your own that doesn't trigger a warning message on the client. Did I understand you correctly? If so, can you point to anything about that at all? If not, I apologize for misinterpreting you. Thanks! 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.
RE: Break it down for n00bs: security problems of non-SSL intrane t?
OK perhaps I got lost in the thread then, you and Dave were giving it some there. What exactly are you saying that can be done ? Russ -Original Message- From: Bobby Hartsfield [mailto:[EMAIL PROTECTED] Sent: 04 October 2006 00:50 To: CF-Talk Subject: RE: Break it down for n00bs: security problems of non-SSL intrane t? Hmm I never tried it with the wrong domain name in the cert. That may or may not work but I personally never said it would or wouldn't ;-) -Original Message- From: Snake [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 03, 2006 7:33 PM To: CF-Talk Subject: RE: Break it down for n00bs: security problems of non-SSL intrane t? I'd like to see that too. I have never seen an invalid cert that doesn't match the domain NOT prompt you with that information. That is the whole point in having them. Russ === Dave said 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. ~| 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:255366 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Break it down for n00bs: security problems of non-SSL intrane t?
Well you could always use the ploy that is being used with spoofed bank sites. User thinks they are going yo www.barclaysbank.co.uk But your really sending them to www.barclayswank.co.uk which has a valid SSL, so nothing looks amis. Russ -Original Message- From: Dave Watts [mailto:[EMAIL PROTECTED] Sent: 04 October 2006 01:05 To: CF-Talk Subject: RE: Break it down for n00bs: security problems of non-SSL intrane t? Not quite sure where I would have lost you at. MiTM... SSL... fake certs... no prompts... Right there between fake certs and no prompts? In this thread, you've said two things: 1. You can trick users into visiting your SSL site instead of someone else's, and they'll click through the wrong hostname warning. 2. You can trick users into visiting your SSL site instead of someone else's, and they won't receive a wrong hostname warning. The lack of said warning would indicate that you've presented them with a valid, signed certificate (or a fake certificate that will pass inspection against the root certificate store of the client) that will correspond to the hostname that the user is actually trying to reach, and will therefore not generate a security warning. Now (1) goes without saying. I'm ok with that. I'm aware of the limitations of relying on users to do the secure thing. But (2) is the sticking point for me. I'm looking for proof of that. It sure seemed to me that that was in fact what you thought when it came to this particular type of attack. Ps. I never mentioned a proxy at any point. I simply said any idiot can set up an SSL proxy. I wasn't referring to you specifically. But a man-in-the-middle attack is, by nature, a proxy - it accepts requests from a client, forwards them to a server, then in turn forwards the response from that server back to the client. 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:255367 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
Re: Break it down for n00bs: security problems of non-SSL intrane t?
On 10/4/06, Snake [EMAIL PROTECTED] wrote: Well you could always use the ploy that is being used with spoofed bank sites. User thinks they are going yo www.barclaysbank.co.uk But your really sending them to www.barclayswank.co.uk which has a valid SSL, so nothing looks amis. Russ I think that was the bit that was confused. Dave keeps asking about how it could be valid, I think this is what Bobby (IIRC) was talking about. It would be a valid cert, but that has little to do with SSL, per se. More that whole, biggest hole is 'tween the user and the screen or whathaveyou. What's swell is that some email clients now warn you if the link says ssl.paypal.com but the actual link is to ssl.playpal.com. Stuff like that could cut down on this crap quite a bit. We don't all need to be chipped. I was watching C-SPAN the other night... I'd always thought that gubment stuff was boring, but man, that was far out. There's a lot going on, out in the open, that I never knew about. The identity stuff and recent big $$ grants got me wondering... People are scaring other people enough as it is, the masses are already clamoring for a more secure internet, only, I don't think they're thinking along the lines of simple link vs. link-text type checking, if you catch my drift. More like how we've got a more secure country, here in the US of A, of late. Hey, at least boot sales are up, right? heh. Encryption is Evil! -V'z ylvat I tried to sub to community, but was unable... ~| 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:255374 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Break it down for n00bs: security problems of non-SSL intrane t?
Well you could always use the ploy that is being used with spoofed bank sites. User thinks they are going yo www.barclaysbank.co.uk But your really sending them to www.barclayswank.co.uk which has a valid SSL, so nothing looks amis. Yes, that'll certainly work. And I enjoyed your example domain names. But I haven't seen any phishing examples that use SSL. Perhaps this is because of the expense. It might also have to do with the verification process that goes along with buying a cert from a public CA. Honestly, I buy few enough certs that I don't know if this is still true, but when I initially ordered my certs from Thawte, I had to verify ownership of the domain and that Fig Leaf was an actual company, etc. That might be a minor impediment to a scammer. 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:255376 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
Re: Break it down for n00bs: security problems of non-SSL intrane t?
On Tuesday 03 October 2006 23:00, Bobby Hartsfield wrote: The only thing left to give you away would be the actual IP address. If someone saw that... say... supersecureremotesite.com was a 10.10.10.10 or 192.168 address (and knew what they were looking at) they might get a You could get around that with a little ARP spoofing and mucking with routing tables. As you've got local access anyway. -- Tom Chiverton Helping to seamlessly visualize efficient technologies This email is sent for and on behalf of Halliwells LLP. Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at St James's Court Brown Street Manchester M2 2JF. A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by the Law Society. CONFIDENTIALITY This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 8008. For more information about Halliwells LLP visit www.halliwells.com. ~| 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:255380 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Break it down for n00bs: security problems of non-SSL intrane t?
Yes the word router has a specific meaning and this IS it. When you actually accomplish a simple mitm, let me know which one you think it is then. You take over for the gateway/router to 'outside' of the network that you are on and ROUTE traffic in it's place. If that's not a router I dont know what is apparently and I'll just stop writing my own firmware for them. You dont have to simply be between one client and the outside world. You can be directing traffic for the entire network... or 'routing' traffic for the entire network. -Original Message- From: Dave Watts [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 03, 2006 11:36 PM To: CF-Talk Subject: RE: Break it down for n00bs: security problems of non-SSL intrane t? If it's either, it's a router considering the steps that need be taken to accomplish the attack and sniff information that the client is sending/receiving from outside the network. The word router has a pretty specific meaning. This isn't it. But w/e... you are just being flippant now anyway. Enjoy. No, I haven't been flippant. I'm sorry you took it that way. 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:255381 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Break it down for n00bs: security problems of non-SSL intrane t?
What exactly are you saying that can be done? You're kidding me right? -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.407 / Virus Database: 268.12.12/462 - Release Date: 10/3/2006 ~| 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:255382 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
RE: Break it down for n00bs: security problems of non-SSL intrane t?
Yes the word router has a specific meaning and this IS it. No, it isn't. When you actually accomplish a simple mitm, let me know which one you think it is then. I sincerely doubt that I will ever accomplish a real attack, since I would have to be either a pen tester or a trespasser to do so. However, I have used ettercap in a lab environment, and that was pretty simple, although I haven't gotten it working on Windows yet. You take over for the gateway/router to 'outside' of the network that you are on and ROUTE traffic in it's place. Routers strip the MAC address info from packets on one network, then rewrite the destination MAC address for the other network. ARP cache poisoning is not routing. If that's not a router I don't know what is apparently and I'll just stop writing my own firmware for them. If I was going to be flippant, this would be the ideal location. You don't have to simply be between one client and the outside world. You can be directing traffic for the entire network... or 'routing' traffic for the entire network. Routing is not routing. Again, routing means something quite specific. Maybe I'm failing to understand what you're trying to say, though. A diagram might be helpful. At this point, I'll simply agree to disagree, if that's ok with you. My thumbs are quite tired. 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:255393 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Break it down for n00bs: security problems of non-SSL intrane t?
I sincerely doubt that I will ever accomplish a real attack, since I would have to be either a pen tester or a trespasser to do so sarcasm Yeah, because you know... those are the only 2 reasons that anyone would try any such thing... /sarcasm Routing is not routing Uhh... ok... is it switching? lol Each conversation with you is a reminder as to why I filtered you in the first place; You'll argue about subjects that you admittedly know little or nothing about... now if I could just remember why the hell I ever took that filter off... bye-bye Dave. -Original Message- From: Dave Watts [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 04, 2006 9:28 AM To: CF-Talk Subject: RE: Break it down for n00bs: security problems of non-SSL intrane t? Yes the word router has a specific meaning and this IS it. No, it isn't. When you actually accomplish a simple mitm, let me know which one you think it is then. I sincerely doubt that I will ever accomplish a real attack, since I would have to be either a pen tester or a trespasser to do so. However, I have used ettercap in a lab environment, and that was pretty simple, although I haven't gotten it working on Windows yet. You take over for the gateway/router to 'outside' of the network that you are on and ROUTE traffic in it's place. Routers strip the MAC address info from packets on one network, then rewrite the destination MAC address for the other network. ARP cache poisoning is not routing. If that's not a router I don't know what is apparently and I'll just stop writing my own firmware for them. If I was going to be flippant, this would be the ideal location. You don't have to simply be between one client and the outside world. You can be directing traffic for the entire network... or 'routing' traffic for the entire network. Routing is not routing. Again, routing means something quite specific. Maybe I'm failing to understand what you're trying to say, though. A diagram might be helpful. At this point, I'll simply agree to disagree, if that's ok with you. My thumbs are quite tired. 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:255401 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: Break it down for n00bs: security problems of non-SSL intrane t?
On Wednesday 04 October 2006 13:49, Bobby Hartsfield wrote: Yes the word router has a specific meaning and this IS it. When you actually accomplish a simple mitm, let me know which one you think it is then. Are you (trying to) claim that proxies like Squid are routers ? -- Tom Chiverton Helping to interactively reinvent sexy synergies This email is sent for and on behalf of Halliwells LLP. Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at St James's Court Brown Street Manchester M2 2JF. A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by the Law Society. CONFIDENTIALITY This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 8008. For more information about Halliwells LLP visit www.halliwells.com. ~| 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:255404 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
RE: Break it down for n00bs: security problems of non-SSL intrane t?
I'm not the one who brought up proxies. And there is no need for squid (or the like) in a common mitm. So no? I'm not? Even remotely? -Original Message- From: Tom Chiverton [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 04, 2006 9:52 AM To: CF-Talk Subject: Re: Break it down for n00bs: security problems of non-SSL intrane t? On Wednesday 04 October 2006 13:49, Bobby Hartsfield wrote: Yes the word router has a specific meaning and this IS it. When you actually accomplish a simple mitm, let me know which one you think it is then. Are you (trying to) claim that proxies like Squid are routers ? -- Tom Chiverton Helping to interactively reinvent sexy synergies This email is sent for and on behalf of Halliwells LLP. Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at St James's Court Brown Street Manchester M2 2JF. A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by the Law Society. CONFIDENTIALITY This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 8008. For more information about Halliwells LLP visit www.halliwells.com. ~| 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:255408 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
Re: Break it down for n00bs: security problems of non-SSL intrane t?
On Wednesday 04 October 2006 15:19, Bobby Hartsfield wrote: I'm not the one who brought up proxies. And there is no need for squid (or the like) in a common mitm. So no? I'm not? Even remotely? Right. So what are you claiming ? -- Tom Chiverton Helping to collaboratively engineer cross-media convergence This email is sent for and on behalf of Halliwells LLP. Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at St James's Court Brown Street Manchester M2 2JF. A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by the Law Society. CONFIDENTIALITY This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 8008. For more information about Halliwells LLP visit www.halliwells.com. ~| 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:255414 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Break it down for n00bs: security problems of non-SSL intrane t?
That in a mitm, you route traffic in place of the router and that makes you NOT a proxy but more so a router? It doesnt much matter it was a stupid argument and I shouldn't have bit... You aren't TECHNIALLY either so who cares. -Original Message- From: Tom Chiverton [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 04, 2006 10:33 AM To: CF-Talk Subject: Re: Break it down for n00bs: security problems of non-SSL intrane t? On Wednesday 04 October 2006 15:19, Bobby Hartsfield wrote: I'm not the one who brought up proxies. And there is no need for squid (or the like) in a common mitm. So no? I'm not? Even remotely? Right. So what are you claiming ? -- Tom Chiverton Helping to collaboratively engineer cross-media convergence This email is sent for and on behalf of Halliwells LLP. Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at St James's Court Brown Street Manchester M2 2JF. A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by the Law Society. CONFIDENTIALITY This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 8008. For more information about Halliwells LLP visit www.halliwells.com. ~| 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:255420 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: Break it down for n00bs: security problems of non-SSL intrane t?
On Wednesday 04 October 2006 16:12, Bobby Hartsfield wrote: That in a mitm, you route traffic in place of the router and that makes you NOT a proxy but more so a router? A router takes packets from one network, and passes them to another, possibly rewriting the headers on the way. A router does not rewrite the contents of the packets. In order to perform a MitM attack, you have to open up and inspect the packets, while acting as a proxy for both the end points (on the route between them). That's much more like what a HTTP or NATP proxy does. Haven't you seen 'Warriors of the Net' :-) It doesnt much matter it was a stupid argument and I shouldn't have bit... You aren't TECHNIALLY I don't think you know enough about me to be able to say that. FWIW I have a long standing background in sys. admin. (started out on Suns and a bit of Windows, moved to Linux of various kinds) and security (one of my jobs was to do just that), as well as ColdFusion (I remember when UDFs were new !). -- Tom Chiverton Helping to continuously develop one-to-one markets This email is sent for and on behalf of Halliwells LLP. Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at St James's Court Brown Street Manchester M2 2JF. A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by the Law Society. CONFIDENTIALITY This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 8008. For more information about Halliwells LLP visit www.halliwells.com. ~| 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:255430 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Break it down for n00bs: security problems of non-SSL intrane t?
LMAO!! Warriors of the net!! Yeah, unfortunately I have seen that lol.. wow flashback. How about dont copy that floppy? lol ok ok... No one ever said anything about rewriting the content of packets (that I remember)... but it only helps support the theory that your computer is more of a router than a proxy during a mitm since no content is being rewritten... In order to perform a MitM attack, you have to open up and inspect the packets You wouldnt inspect or rewrite anything more than a router would. All you have to do is adjust the headers (just like the router does) for local traffic then send the packets out the NIC that you are monitoring. Ethereal, Ettercap or whatever monitor you are using reads the rest of the packet. You aren't TECHNIALLY I don't think you know enough about me to be able to say that. I DIDNT say that. Comment me in context please. If you simply misunderstood that then it meant you (as in your computer) arent TECHNICALLY a router OR a proxy during a mitm so it doesnt matter Ps... Outlook says 'ettercap' is misspelled and wants to correct it with 'Ethereal' and I found it amusing and thought I'd share. -Original Message- From: Tom Chiverton [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 04, 2006 11:53 AM To: CF-Talk Subject: Re: Break it down for n00bs: security problems of non-SSL intrane t? On Wednesday 04 October 2006 16:12, Bobby Hartsfield wrote: That in a mitm, you route traffic in place of the router and that makes you NOT a proxy but more so a router? A router takes packets from one network, and passes them to another, possibly rewriting the headers on the way. A router does not rewrite the contents of the packets. In order to perform a MitM attack, you have to open up and inspect the packets, while acting as a proxy for both the end points (on the route between them). That's much more like what a HTTP or NATP proxy does. Haven't you seen 'Warriors of the Net' :-) It doesnt much matter it was a stupid argument and I shouldn't have bit... You aren't TECHNIALLY I don't think you know enough about me to be able to say that. FWIW I have a long standing background in sys. admin. (started out on Suns and a bit of Windows, moved to Linux of various kinds) and security (one of my jobs was to do just that), as well as ColdFusion (I remember when UDFs were new !). -- Tom Chiverton Helping to continuously develop one-to-one markets This email is sent for and on behalf of Halliwells LLP. Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at St James's Court Brown Street Manchester M2 2JF. A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by the Law Society. CONFIDENTIALITY This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 8008. For more information about Halliwells LLP visit www.halliwells.com. ~| 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:255436 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
RE: Break it down for n00bs: security problems of non-SSL intrane t?
sarcasm Yeah, because you know... those are the only 2 reasons that anyone would try any such thing... /sarcasm Seriously, what's a third reason why you might attack someone else's network? Routing is not routing Uhh... ok... is it switching? Lol You had routing in quotes earlier, but were describing something that isn't actually routing. Each conversation with you is a reminder as to why I filtered you in the first place; You'll argue about subjects that you admittedly know little or nothing about... now if I could just remember why the hell I ever took that filter off... bye-bye Dave. I qualify what I say when I don't know something. I am open to the possibility that I'm wrong. However, I require facts to be convinced I'm wrong. You seem to be unable to supply any facts. Either you have none, or you lack a rudimentary grasp of English. Perhaps both. Good luck with your smartass schtick, though. 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:255480 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Break it down for n00bs: security problems of non-SSL intrane t?
smartass shtick Pot -- kettle? -Original Message- From: Dave Watts [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 04, 2006 1:56 PM To: CF-Talk Subject: RE: Break it down for n00bs: security problems of non-SSL intrane t? sarcasm Yeah, because you know... those are the only 2 reasons that anyone would try any such thing... /sarcasm Seriously, what's a third reason why you might attack someone else's network? Routing is not routing Uhh... ok... is it switching? Lol You had routing in quotes earlier, but were describing something that isn't actually routing. Each conversation with you is a reminder as to why I filtered you in the first place; You'll argue about subjects that you admittedly know little or nothing about... now if I could just remember why the hell I ever took that filter off... bye-bye Dave. I qualify what I say when I don't know something. I am open to the possibility that I'm wrong. However, I require facts to be convinced I'm wrong. You seem to be unable to supply any facts. Either you have none, or you lack a rudimentary grasp of English. Perhaps both. Good luck with your smartass schtick, though. 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:255492 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: Break it down for n00bs: security problems of non-SSL intrane t?
On 10/4/06, Dave Watts [EMAIL PROTECTED] wrote: Seriously, what's a third reason why you might attack someone else's network? The quest for knowledge! Seriously, replace attack with some nicer word, and maybe you have an argument like I was testing the lock, so to speak. Seeing as how one might be liable, for how someone else set things up- it might be a valid argument. But doing that stuff might be frowned on in someplace like you've described working, where they have their own byte security teams and what not. (those guys get paid some $$). Not that one who is paranoid would take that at face value- high dollar, super trained team as it may be. But that one is probably more of a freelancer anyway. Which is good, cuz, hey, look at how much of this stuff is outsourced. I'm telling you, this whole conversation makes me ache for a spam echelon day... Let's continue this thread using only encrypted posts, fer kicks. Those of us who aren't black listed, of course. LOL. =] I'm going to go try community again. Peace out-tees 5000 - |}en* (I am smiling while I read though, which is better than frown-coding, right?) ~| 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:255587 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: Break it down for n00bs: security problems of non-SSL intrane t?
On Monday 02 October 2006 23:32, Dave Watts wrote: certificate. The only effective man-in-the-middle attack you could make here is if you tricked people into going to your site instead of the target site, then had your site make SSL requests to the target site .. prohibitively expensive to examine. SSL doesn't just encrypt the traffic, it handles key exchange in a relatively secure way. There are web proxies / response mangerling programs that perform this exact job for debugging purposes, just to throw an idea out there. -- Tom Chiverton Helping to synergistically e-enable advanced networks This email is sent for and on behalf of Halliwells LLP. Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at St James's Court Brown Street Manchester M2 2JF. A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by the Law Society. CONFIDENTIALITY This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 8008. For more information about Halliwells LLP visit www.halliwells.com. ~| 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:255125 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
RE: Break it down for n00bs: security problems of non-SSL intrane t?
Do you know what a MItM attack is? Middle is just that... the middle. Middle of what? The very same endpoints you mentioned... the client and the server. Basically you trick the client into believing you are the server and trick the server into thinking you are the client so all traffic between the 2 'endpoints' is routed through you... you then 'generously' forward said traffic it to its' rightful destination. I'm well aware what a man-in-the-middle attack is, thanks. SSL is not especially vulnerable to this, because it verifies the identity of both endpoints and provides secure key exchange between said endpoints. This only applies to certificates signed by a trusted CA, of course, and there have been specific bugs in specific products such as IE that have broken this, but SSL, properly configured and used, protects pretty well against those attacks. 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:255141 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
RE: Break it down for n00bs: security problems of non-SSL intrane t?
Well, like I said... wrong. -Original Message- From: Dave Watts [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 03, 2006 8:40 AM To: CF-Talk Subject: RE: Break it down for n00bs: security problems of non-SSL intrane t? Do you know what a MItM attack is? Middle is just that... the middle. Middle of what? The very same endpoints you mentioned... the client and the server. Basically you trick the client into believing you are the server and trick the server into thinking you are the client so all traffic between the 2 'endpoints' is routed through you... you then 'generously' forward said traffic it to its' rightful destination. I'm well aware what a man-in-the-middle attack is, thanks. SSL is not especially vulnerable to this, because it verifies the identity of both endpoints and provides secure key exchange between said endpoints. This only applies to certificates signed by a trusted CA, of course, and there have been specific bugs in specific products such as IE that have broken this, but SSL, properly configured and used, protects pretty well against those attacks. 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:255142 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Break it down for n00bs: security problems of non-SSL intrane t?
Well, like I said... wrong. I guess I can't argue with that. How about a link, or something? 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:255143 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
RE: Break it down for n00bs: security problems of non-SSL intrane t?
Again, like I said... I left details out intentionally and I won't post them now just because you asked. I'm certain you can find more details out there in that vast world of info. I'm also sure it's probably been detailed by some fame crazed wannabe who has grabbed onto the recent IPTV craze and spilled all his/her dirty little tricks/secrets in an attempt to trade knowledge for a pathetic fan base just to feel less friendless. -Original Message- From: Dave Watts [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 03, 2006 9:05 AM To: CF-Talk Subject: RE: Break it down for n00bs: security problems of non-SSL intrane t? Well, like I said... wrong. I guess I can't argue with that. How about a link, or something? 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:255147 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
RE: Break it down for n00bs: security problems of non-SSL intrane t?
Again, like I said... I left details out intentionally and I won't post them now just because you asked. OK. I can understand that you don't want to release this sensitive information to the world. But typically, one could point to something which would describe the existence of a vulnerability without disclosing exactly how to exploit it. And presumably, this would be a big huge deal to all the SSL VPN vendors, browser developers - patches, warnings, etc. So, it seems to me that either (a) you're aware of some otherwise unknown 0day exploit, or (b) all the people using SSL/TLS in their products are collectively hoping that no one notices their fatal flaw until they can patch it. To be clear, are you talking about certificates with a validating signature? Because if you're talking about self-signed certs, that's been discussed previously. 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:255165 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
RE: Break it down for n00bs: security problems of non-SSL intrane t?
Because if you're talking about self-signed certs, that's been discussed previously They weren't discussed, they were mentioned with the assumption that they won't validate and/or would be easily detected by a prompt to accept them unless they were stolen or bought... that assumption is wrong. It has nothing to do with all the SSL VPN vendors, browser developers - patches, warnings, etc. Best protection? Have a guard stand by every computer on the network and watch each user's every move because it's the 'only' way to keep it from happening. -Original Message- From: Dave Watts [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 03, 2006 10:35 AM To: CF-Talk Subject: RE: Break it down for n00bs: security problems of non-SSL intrane t? Again, like I said... I left details out intentionally and I won't post them now just because you asked. OK. I can understand that you don't want to release this sensitive information to the world. But typically, one could point to something which would describe the existence of a vulnerability without disclosing exactly how to exploit it. And presumably, this would be a big huge deal to all the SSL VPN vendors, browser developers - patches, warnings, etc. So, it seems to me that either (a) you're aware of some otherwise unknown 0day exploit, or (b) all the people using SSL/TLS in their products are collectively hoping that no one notices their fatal flaw until they can patch it. To be clear, are you talking about certificates with a validating signature? Because if you're talking about self-signed certs, that's been discussed previously. 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:255172 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: Break it down for n00bs: security problems of non-SSL intrane t?
On Tuesday 03 October 2006 15:35, Dave Watts wrote: [a very nice attempt to get Bobby to explain] Rule number one from Mythological Beasts on Mailing Lists states do not feed in the section on sub-bridge dwellers :-) -- Tom Chiverton Helping to revolutionarily strategize professional networks This email is sent for and on behalf of Halliwells LLP. Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at St James's Court Brown Street Manchester M2 2JF. A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by the Law Society. CONFIDENTIALITY This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 8008. For more information about Halliwells LLP visit www.halliwells.com. ~| 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:255184 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Break it down for n00bs: security problems of non-SSL intrane t?
I think the question was are you talking about certificates with a validating signature? and I think I answered that... more or less. If it wasn't clear, then YES I am talking about generated certs that will validate 100% locally. If by sub-bridge you mean 'the real world' where people know better than to think ANYTHING is secure on a network when the 'bad guy' has local access and knows what he/she is doing, then yeah... that's where I live. Putting faith in SSL to protect against local attacks is absurd. Claiming that setting it up 'correctly' protects better against local MiTM attacks is nothing short of naïve. -Original Message- From: Tom Chiverton [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 03, 2006 11:13 AM To: CF-Talk Subject: Re: Break it down for n00bs: security problems of non-SSL intrane t? On Tuesday 03 October 2006 15:35, Dave Watts wrote: [a very nice attempt to get Bobby to explain] Rule number one from Mythological Beasts on Mailing Lists states do not feed in the section on sub-bridge dwellers :-) -- Tom Chiverton Helping to revolutionarily strategize professional networks This email is sent for and on behalf of Halliwells LLP. Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at St James's Court Brown Street Manchester M2 2JF. A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by the Law Society. CONFIDENTIALITY This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 8008. For more information about Halliwells LLP visit www.halliwells.com. ~| 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:255194 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Break it down for n00bs: security problems of non-SSL intrane t?
SSL does not protect against the man in the middle attack because it doesn't validate the identity of the client (which is done with client certificates, and even then I'm not sure if it would help against the man in the middle attack). SSL is not a flaw in the case. It just doesn't prevent the man in the middle attack, but it doesn't do anything to facilitate it. Back to the original question. You should use SSL because otherwise your traffic travels in cleartext, including username's and passwords, and can be sniffed on the wire at any point along the route. At hacker conventions they often set up a wall of shame, by running a script which sniffs all network traffic and posts the usernames and passwords on the wall for people who use insecure protocols (SMTP, POP3, IMAP, FTP, etc). Even if you use some sort of encryption, it's vulnerable to the man in the middle attack. As mentioned before, this attack is not trivial, as it requires either tricking the person into going to a different domain name and then proxying the requests, or doing some sort of DNS/arp poisoning. The DNS/arp poisoning is not easy either, unless the attacker gains access to your dns records, or is on the local network. If an attacker is able to modify the hosts file on the client computer, he has everything he needs to do a man in the middle attack. These attacks are not done very often in practice, however. There are easier ways to obtain information, such as social engineering. Russ -Original Message- From: Bobby Hartsfield [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 03, 2006 10:59 AM To: CF-Talk Subject: RE: Break it down for n00bs: security problems of non-SSL intrane t? Because if you're talking about self-signed certs, that's been discussed previously They weren't discussed, they were mentioned with the assumption that they won't validate and/or would be easily detected by a prompt to accept them unless they were stolen or bought... that assumption is wrong. It has nothing to do with all the SSL VPN vendors, browser developers - patches, warnings, etc. Best protection? Have a guard stand by every computer on the network and watch each user's every move because it's the 'only' way to keep it from happening. -Original Message- From: Dave Watts [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 03, 2006 10:35 AM To: CF-Talk Subject: RE: Break it down for n00bs: security problems of non-SSL intrane t? Again, like I said... I left details out intentionally and I won't post them now just because you asked. OK. I can understand that you don't want to release this sensitive information to the world. But typically, one could point to something which would describe the existence of a vulnerability without disclosing exactly how to exploit it. And presumably, this would be a big huge deal to all the SSL VPN vendors, browser developers - patches, warnings, etc. So, it seems to me that either (a) you're aware of some otherwise unknown 0day exploit, or (b) all the people using SSL/TLS in their products are collectively hoping that no one notices their fatal flaw until they can patch it. To be clear, are you talking about certificates with a validating signature? Because if you're talking about self-signed certs, that's been discussed previously. 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:255196 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Break it down for n00bs: security problems of non-SSL intrane t?
SSL does not protect against the man in the middle attack because it doesn't validate the identity of the client (which is done with client certificates, and even then I'm not sure if it would help against the man in the middle attack). Why wouldn't it, exactly? Client certificates use the same sort of functionality that server certificates do, as far as validation goes. If you need to validate both endpoints, you will need certificates on both. But in my experience, this is pretty common in large enterprises - many large organizations run their own certificate authorities just for this. If an attacker is able to modify the hosts file on the client computer, he has everything he needs to do a man in the middle attack. Of course, at this point, the attacker can do all sorts of things without resorting to that kind of attack. But yes, both the client and the server must be adequately secure to prevent these sorts of things. 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:255228 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
RE: Break it down for n00bs: security problems of non-SSL intrane t?
I think the question was are you talking about certificates with a validating signature? and I think I answered that... more or less. If it wasn't clear, then YES I am talking about generated certs that will validate 100% locally. I remember an exploit specific to IE around 2001 or so, in which IE would accept any cert from one cert vendor as valid, even if the hostname didn't match. I do think that was patched since then. I also remember a big problem with intermediate certs around 2002, which affected pretty much every vendor using SSL. I'm unaware of any current vulnerabilities like this, although obviously that doesn't mean they don't exist. If by sub-bridge you mean 'the real world' where people know better than to think ANYTHING is secure on a network when the 'bad guy' has local access and knows what he/she is doing, then yeah... that's where I live. Putting faith in SSL to protect against local attacks is absurd. Claiming that setting it up 'correctly' protects better against local MiTM attacks is nothing short of naïve. I'm not really sure what you mean by local access, or the real world for that matter. If by local access you mean access (and potential control) of an endpoint in an SSL conversation, then yeah, you've just described the whole problem with clientless SSL VPNs in a nutshell. But that's not what anyone here (other than you, perhaps) is talking about, as far as I can tell. And in the real world I live in, when I visit client sites, they are often quite secure, to the point where moving a machine from one wall jack to another requires administrative intervention (and triggers alarms if you do it yourself). And I'm not trying to be a dick about this, to be blunt. I don't think you're trolling. I am not a security expert. There are a lot of things I don't know, to say the least. But your response was essentially Oooga booga, you should be scared because I say so! That's not especially convincing. I'm familiar with using, say, Ettercap to capture HTTPS sessions, but again, I've never seen an example where this didn't rely on presenting an invalid certificate to the user. 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:255251 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Break it down for n00bs: security problems of non-SSL intrane t?
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. You are thinking of vulnerabilities in the make up of certs/SSL and there arent any (that I know of) and that plays into it as well by keeping the client user comfortable and happy thinking everything is secure. Dont 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. 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 werent encrypted? That is the key and that is easily done without prompting anyone to accept anything. (and I guess the part you dont believe can be accomplished?) The only thing left to give you away would be the actual IP address. If someone saw that... say... supersecureremotesite.com was a 10.10.10.10 or 192.168 address (and knew what they were looking at) they might get a little suspicious but who is going to check the IP address of a commonly visited, secure site when they see no need to? And yes, IPs are flashed in the status bar of browsers while downloading content sometimes so there's another potential give away. 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 werent asked to accept the cert. And in the real world I live in, when I visit client sites, they Are often quite secure, to the point where moving a machine from one wall jack to another requires administrative intervention (and triggers alarms if you do it yourself). 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 thats awesome but everywhere you go isn't like that or even close. Sorry. I'm familiar with using, say, Ettercap to capture HTTPS sessions, but again, I've never seen an example where this didn't rely on presenting an invalid certificate to the user. Of course it requires presenting an invalid cert. How else could it be done? They key is getting the cert accepted without user interaction. If by local access you mean access (and potential control) of an endpoint in an SSL conversation, then yeah, you've just described the whole problem with clientless SSL VPNs in a nutshell. But that's not what anyone here (other than you, perhaps) is talking about, as far as I can tell. 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... 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 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 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.407 / Virus Database: 268.12.12/461 - Release Date: 10/2/2006 ~| 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:255282 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
RE: Break it down for n00bs: security problems of non-SSL intrane t?
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
RE: Break it down for n00bs: security problems of non-SSL intrane t?
I'd like to see that too. I have never seen an invalid cert that doesn't match the domain NOT prompt you with that information. That is the whole point in having them. Russ === Dave said 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. ~| 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:255292 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
RE: Break it down for n00bs: security problems of non-SSL intrane t?
I wasn't sure whether you mean access to a local machine or access to a local network segment. I was under the impression we were all on the same page there since the thread was about an intranet. It's worth pointing out that network administrators can disable the ability of It's worth mentioning that there are quite a few things Admins can do to thwart these attack attempts. Your description of some networks around there sound promising. Educating the uneducated users on your network is always number 1 though. Well, sure, but that's not what you mentioned earlier at all. Did I lose myself somewhere? What did I NOT mention earlier at all? I should qualify that by mentioning that I work in DC, I guess. Yeah, I would imagine a lot of networks around there are more secure than say... BFE and Jim-Bob's network (where I am from) lol And, I've had trouble figuring out exactly what you've been trying to say, so I thought I'd cover all the bases. Not quite sure where I would have lost you at. MiTM... SSL... fake certs... no prompts... I don't think that, alone, the use of SSL is a security panacea It sure seemed to me that that was in fact what you thought when it came to this particular type of attack. Ps. I never mentioned a proxy at any point. -Original Message- From: Dave Watts [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 03, 2006 7:11 PM To: CF-Talk Subject: RE: Break it down for n00bs: security problems of non-SSL intrane t? 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
RE: Break it down for n00bs: security problems of non-SSL intrane t?
Hmm I never tried it with the wrong domain name in the cert. That may or may not work but I personally never said it would or wouldn't ;-) -Original Message- From: Snake [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 03, 2006 7:33 PM To: CF-Talk Subject: RE: Break it down for n00bs: security problems of non-SSL intrane t? I'd like to see that too. I have never seen an invalid cert that doesn't match the domain NOT prompt you with that information. That is the whole point in having them. Russ === Dave said 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. ~| 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:255295 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
RE: Break it down for n00bs: security problems of non-SSL intrane t?
Not quite sure where I would have lost you at. MiTM... SSL... fake certs... no prompts... Right there between fake certs and no prompts? In this thread, you've said two things: 1. You can trick users into visiting your SSL site instead of someone else's, and they'll click through the wrong hostname warning. 2. You can trick users into visiting your SSL site instead of someone else's, and they won't receive a wrong hostname warning. The lack of said warning would indicate that you've presented them with a valid, signed certificate (or a fake certificate that will pass inspection against the root certificate store of the client) that will correspond to the hostname that the user is actually trying to reach, and will therefore not generate a security warning. Now (1) goes without saying. I'm ok with that. I'm aware of the limitations of relying on users to do the secure thing. But (2) is the sticking point for me. I'm looking for proof of that. It sure seemed to me that that was in fact what you thought when it came to this particular type of attack. Ps. I never mentioned a proxy at any point. I simply said any idiot can set up an SSL proxy. I wasn't referring to you specifically. But a man-in-the-middle attack is, by nature, a proxy - it accepts requests from a client, forwards them to a server, then in turn forwards the response from that server back to the client. 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:255298 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Break it down for n00bs: security problems of non-SSL intrane t?
A MItM attack is more or less making your self the router... not a proxy. I never said anything about sending a user to any site other than the real one. Sorry, I dont know where you get that from. -Original Message- From: Dave Watts [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 03, 2006 8:05 PM To: CF-Talk Subject: RE: Break it down for n00bs: security problems of non-SSL intrane t? Not quite sure where I would have lost you at. MiTM... SSL... fake certs... no prompts... Right there between fake certs and no prompts? In this thread, you've said two things: 1. You can trick users into visiting your SSL site instead of someone else's, and they'll click through the wrong hostname warning. 2. You can trick users into visiting your SSL site instead of someone else's, and they won't receive a wrong hostname warning. The lack of said warning would indicate that you've presented them with a valid, signed certificate (or a fake certificate that will pass inspection against the root certificate store of the client) that will correspond to the hostname that the user is actually trying to reach, and will therefore not generate a security warning. Now (1) goes without saying. I'm ok with that. I'm aware of the limitations of relying on users to do the secure thing. But (2) is the sticking point for me. I'm looking for proof of that. It sure seemed to me that that was in fact what you thought when it came to this particular type of attack. Ps. I never mentioned a proxy at any point. I simply said any idiot can set up an SSL proxy. I wasn't referring to you specifically. But a man-in-the-middle attack is, by nature, a proxy - it accepts requests from a client, forwards them to a server, then in turn forwards the response from that server back to the client. 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:255302 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
RE: Break it down for n00bs: security problems of non-SSL intrane t?
A MItM attack is more or less making your self the router... not a proxy. I don't think that's correct. Routers separate networks, and forward traffic from one network to another, not from one host to another. And, for what it's worth, most of the Mallory tools I've seen are called proxies. I never said anything about sending a user to any site other than the real one. Sorry, I don't know where you get that from. If you send a user to your proxy instead of letting the user communicate directly to the site, you are sending the user to a site other than the real one. 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:255310 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Break it down for n00bs: security problems of non-SSL intrane t?
If it's either, it's a router considering the steps that need be taken to accomplish the attack and sniff information that the client is sending/receiving from outside the network. But w/e... you are just being flippant now anyway. Enjoy. -Original Message- From: Dave Watts [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 03, 2006 10:44 PM To: CF-Talk Subject: RE: Break it down for n00bs: security problems of non-SSL intrane t? A MItM attack is more or less making your self the router... not a proxy. I don't think that's correct. Routers separate networks, and forward traffic from one network to another, not from one host to another. And, for what it's worth, most of the Mallory tools I've seen are called proxies. I never said anything about sending a user to any site other than the real one. Sorry, I don't know where you get that from. If you send a user to your proxy instead of letting the user communicate directly to the site, you are sending the user to a site other than the real one. 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:255312 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
RE: Break it down for n00bs: security problems of non-SSL intrane t?
If it's either, it's a router considering the steps that need be taken to accomplish the attack and sniff information that the client is sending/receiving from outside the network. The word router has a pretty specific meaning. This isn't it. But w/e... you are just being flippant now anyway. Enjoy. No, I haven't been flippant. I'm sorry you took it that way. 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:255320 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
RE: Break it down for n00bs: security problems of non-SSL intrane t?
What are the security implications of having an intranet *not* secured using SSL when it is behind an existing beefy hardware firewall? I know it is standard practice to do so, but what are the legit reasons for it? The site in question runs on a cluster of ColdFusion 5 boxes running Linux (unknown distro) and Apache 1.3.x. Would it be possible to snoop data on connections to these servers and if so what tools would I use to do so? Don't worry about the legalities of answering this, I have full authority to do so. The security implication, whether it's a public or private site, is that information is exchanged between the client and the server in plaintext, and that anyone with physical access to any network segment used to exchange that information can read it. The only difference between internet and intranet sites here is the number of potential listeners on any given network segment. Any idiot with local administrative rights can use Ethereal, uh, I mean Wireshark to read all of the data exchanged between his machine and other machines. It's also usually pretty easy to use your network card's support for promiscuous mode to read all of the data exchanged on that network segment between other machines, although some network administrators are on the lookout for NICs in promiscuous mode. 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 and 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:255091 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Break it down for n00bs: security problems of non-SSL intrane t?
Internally... you can sniff whatever you want with a man in the middle 'attack'. SSL would just encrypt the payload making it harder to get at. (There are of course ways around that) SSL on an internal network would do nothing but slow someone down or add an extra step to the sniffing process (an easy step). This is far from being a trivial thing to do. When you use SSL certificates, the certificate does two things. First, of course, it enables end-to-end encryption. Second, and equally important here, it verifies that a host is what it says it is. For example, if you go to https://training.figleaf.com/, the installed certificate says I belong to training.figleaf.com, and if I installed it on tra1ning.fugleaf.com, you would get a certificate error when you browsed the site, which would tell you that the certificate doesn't match with the host presenting said certificate. The only effective man-in-the-middle attack you could make here is if you tricked people into going to your site instead of the target site, then had your site make SSL requests to the target site on the original user's behalf, and because of the certificate verification, this is unlikely to succeed. Second, if you are able to connect to a verified host via SSL, SSL traffic cannot be examined, practically speaking, unless you can examine it at one endpoint or the other (the client or the server). In between, it is prohibitively expensive to examine. SSL doesn't just encrypt the traffic, it handles key exchange in a relatively secure way. 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:255093 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
RE: Break it down for n00bs: security problems of non-SSL intrane t?
Well first of all if you don't use a real certificate authority, but install a self generated certificate, then using the man in the middle attack, the other pc can install a self generated cert, and you wouldn't know it, since all you would get is a warning. This of course requires dns/arp poisoning to implement. If you use a real certificate from one of the certificate authorities, the man in the middle can do 1 of 2 things (after they've done the dns/arp poisoning). 1. Steal the certificate from your server and install it on theirs 2. Somehow get access to make changes to the domain registration or to read the domain registration contact emails, and then buy their own certificate. The scenario you've presented where the user goes to 'bad' site and the 'bad' site accesses the 'good' site as a proxy, the 'bad' site administrator can buy the certificate for their domain name, and no warning will be issued. In your example, I would buy a certificate for tra1ning.fugleaf.com and trick the user into going there. Russ -Original Message- From: Dave Watts [mailto:[EMAIL PROTECTED] Sent: Monday, October 02, 2006 6:33 PM To: CF-Talk Subject: RE: Break it down for n00bs: security problems of non-SSL intrane t? Internally... you can sniff whatever you want with a man in the middle 'attack'. SSL would just encrypt the payload making it harder to get at. (There are of course ways around that) SSL on an internal network would do nothing but slow someone down or add an extra step to the sniffing process (an easy step). This is far from being a trivial thing to do. When you use SSL certificates, the certificate does two things. First, of course, it enables end-to-end encryption. Second, and equally important here, it verifies that a host is what it says it is. For example, if you go to https://training.figleaf.com/, the installed certificate says I belong to training.figleaf.com, and if I installed it on tra1ning.fugleaf.com, you would get a certificate error when you browsed the site, which would tell you that the certificate doesn't match with the host presenting said certificate. The only effective man-in-the-middle attack you could make here is if you tricked people into going to your site instead of the target site, then had your site make SSL requests to the target site on the original user's behalf, and because of the certificate verification, this is unlikely to succeed. Second, if you are able to connect to a verified host via SSL, SSL traffic cannot be examined, practically speaking, unless you can examine it at one endpoint or the other (the client or the server). In between, it is prohibitively expensive to examine. SSL doesn't just encrypt the traffic, it handles key exchange in a relatively secure way. 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:255101 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Break it down for n00bs: security problems of non-SSL intrane t?
Well first of all if you don't use a real certificate authority, but install a self generated certificate, then using the man in the middle attack, the other pc can install a self generated cert, and you wouldn't know it, since all you would get is a warning. This of course requires dns/arp poisoning to implement. Yes, self-signed certificates do not provide the validation that comes with a certificate signed by a trusted certificate authority. That is one of the obvious limitations of self-signed certificates, I would think. If you use a real certificate from one of the certificate authorities, the man in the middle can do 1 of 2 things (after they've done the dns/arp poisoning). 1. Steal the certificate from your server and install it on theirs 2. Somehow get access to make changes to the domain registration or to read the domain registration contact emails, and then buy their own certificate. Note that I didn't say it couldn't be done. I said it would not be trivial. I think you've just demonstrated that, with your explanation. Multiple security vulnerabilities would need to exist. And if I could steal the certificate from your server, I doubt I'd need to go to all this trouble, as I'd obviously have some sort of control over one of the two vulnerable SSL endpoints, and I could probably just query the databases, etc, directly anyway. The scenario you've presented where the user goes to 'bad' site and the 'bad' site accesses the 'good' site as a proxy, the 'bad' site administrator can buy the certificate for their domain name, and no warning will be issued. In your example, I would buy a certificate for tra1ning.fugleaf.com and trick the user into going there. This is certainly more viable, as the current success of phishing exploits demonstrates. However, within the context of an intranet environment - the environment described by the original poster - this is much less likely to succeed. Most employees presumably know the domain name of their employer, for example. 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:255103 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Break it down for n00bs: security problems of non-SSL intrane t?
The only effective man-in-the-middle attack you could make here is if you tricked people into going to your site instead of the target site Wrong. I left out details intentionally but believe me... it's NOT the only effective method of a MItM attack. Second, if you are able to connect to a verified host via SSL, SSL traffic cannot be examined, practically speaking, unless you can examine it at one endpoint or the other (the client or the server). In between, it is prohibitively expensive to examine Do you know what a MItM attack is? Middle is just that... the middle. Middle of what? The very same endpoints you mentioned... the client and the server. Basically you trick the client into believing you are the server and trick the server into thinking you are the client so all traffic between the 2 'endpoints' is routed through you... you then 'generously' forward said traffic it to its' rightful destination. -Original Message- From: Dave Watts [mailto:[EMAIL PROTECTED] Sent: Monday, October 02, 2006 6:33 PM To: CF-Talk Subject: RE: Break it down for n00bs: security problems of non-SSL intrane t? Internally... you can sniff whatever you want with a man in the middle 'attack'. SSL would just encrypt the payload making it harder to get at. (There are of course ways around that) SSL on an internal network would do nothing but slow someone down or add an extra step to the sniffing process (an easy step). This is far from being a trivial thing to do. When you use SSL certificates, the certificate does two things. First, of course, it enables end-to-end encryption. Second, and equally important here, it verifies that a host is what it says it is. For example, if you go to https://training.figleaf.com/, the installed certificate says I belong to training.figleaf.com, and if I installed it on tra1ning.fugleaf.com, you would get a certificate error when you browsed the site, which would tell you that the certificate doesn't match with the host presenting said certificate. The only effective man-in-the-middle attack you could make here is if you tricked people into going to your site instead of the target site, then had your site make SSL requests to the target site on the original user's behalf, and because of the certificate verification, this is unlikely to succeed. Second, if you are able to connect to a verified host via SSL, SSL traffic cannot be examined, practically speaking, unless you can examine it at one endpoint or the other (the client or the server). In between, it is prohibitively expensive to examine. SSL doesn't just encrypt the traffic, it handles key exchange in a relatively secure way. 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:255115 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
