Re: FQDN as subjectAltName
Sry finally found where I did wrong. I should change the FQDN in the x509v3.cnf file that where it take info to make the x509 cert Thx to all anyway On 3/13/06, Doug Frippon [EMAIL PROTECTED] wrote: I've just figure out something, with the openssl x509 -in mycert.crt -noout -text command, Isaw that there is the same subjectAltName in my two cert. I'm sure that I diodn't wrote the same in both of them, but seems like if some one have modify it. =-) BTW I've add the subjectAltNmae by writting down subjectAltName=FQDN:somehost.somedomain in the usr_cert section of openssl.cnf file I also modified it between the creation of both cert to match the cert I was creating. What did I do wrong Hope someone can Help!!! Doug2die4 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: FQDN
I still don't understand where you're disagreeing with me. Your attack includes things like hijacking and redirection, which is not part of an MITM attack. Your postings also seem to come down on both sides of succesful as to whether or not that is part of MITM. If the MITM isn't intercepting or modifying the traffic *between A and B* it is not MITM. If A and B -- the participants that originally intended to communicate -- don't end up having (compromised) communication, than it is not MITM. If there's out of band signalling that the A:B comm channel has been attacked, than the protocol is *not* protected against MITM. Or, you must include the OOB information as part of the protocol. :) /r$ PS: 35 web sites either got the definition wrong, or weren't clear enough for you to understand? I'm not swayed. -- Rich Salz Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: FQDN
Hi David, I'm going to exist myself from this discussion at the conclusion of this mail - it's consumed enough list bandwidth without further eating into my own limited resources. Clipping; On July 25, 2003 11:48 pm, David Schwartz wrote: [snip] Not at all. SSL with comparison of the certificate name to name of the intended recipient is invulnerable to MITM attacks. All a MITM can do is prevent data from being exchanged. (And, of course, a MITM can always do that.) [snip] How will you know something's wrong if you don't compare the name in the certificate to the name of the server you intended to speak to? That's not part of SSL/TLS. SSL/TLS itself is vulnerable to plaintext compromise from a MITM attack unless you confirm the certificate in some way. [snip] You are confusing SSL/TLS with use-cases for SSL/TLS. SSL/TLS gives you protection against MITM attacks modulo the identity assurances you can determine (and define) from X509. What you do with X509 is your business and if you foul that up (or ignore it, which amounts to the same thing) then *you* are vulnerable to MITM. Saying SSL/TLS itself is vulnerable to MITM unless you do something extra that's not defined in SSL/TLS is like saying a home alarm system is provides no protection against intrusion until you install it in a house. NB: OpenSSL's *implementation* will attempt to provide a *correct* handling of X509, but will not magically conjur up context for you. Ie. it should apply expiry checking, constraints, etc. It will not check certificate fields for intended peer information, because it doesn't know the application, the requirements, or the transport (you know, BIOs exist for more than just hiding TCP/IPv4 ...). A MITM can deny service. A MITM can make himself known. A MITM can fail to obtain any plaintext. All of these things are within the scope of what a MITM can do, they just might fail to make successful attacks. [snip] You are trying to bamboozle us, I think. A MITM in your world is any programmable location between the end-points who does anything except ignore your traffic. Fine, whatever. This is not even relevant for discussing MITM attacks on poortly implemented HTTPS applications, and is ludicrous in trying to wiggle the MITM term into the SSL/TLS protocol itself by games of definition. I'm sorry you've spent so much time on google over this - that can't have been much fun. Trying to make sense of this thread, and feeling obliged to wade in when it risked staining the archives and misleading impressionable users, has not been much fun for me either. Please think more carefully about what SSL/TLS is defined as - you won't find host names, or even transport details. There is a reason for this, and the fact Netscape (and subsequent parties) have so carefully made sure to keep use-case specifics out of the specs is further evidence that the layering is no accident. Indeed these parties have almost exclusively shared a common intended use, yet they kept the protocol definition free of those details. Please share their enlightenment. I'm not going to waste space disagreeing with you about HTTPS, but that's because (a) I don't necessarily disagree, and (b) as far as this mail-list is concerned, I couldn't care less about HTTPS. Really. I'm amazed that you would disagree with every published definition of a MITM I could find. An explanation of an acryonym does not give it the context that it assumes in the field over time. Man In The Middle is a pretty symbollic phrase, appropriate for discussing diplomacy, customer support, and would probably make a pretty naff (and successful) pop song. MITM attack is already something more refined. Moreover, the layer you are discussing it at, as well as which particular aspect of that layer, matters. You can discuss MITM attacks against IPv4 and/or HTTPS all you like. Likewise you can discuss MITM attacks against X509 until you are blue in the face. If you want to discuss MITM attacks against the *SSL/TLS protocol* then you have been wildly overreaching. And to shuffle your feet around what you actually mean by attack, to the extent that any disruption or nuisance-making at the wire-level automatically counts as a MITM attack on SSL/TLS, can only hold water if you define it to. But that takes you outside any reasonable definition that matters to anyone else. Anyway like Brian, that's all I have to say on this, for whatever it's worth. Cheers, Geoff -- Geoff Thorpe [EMAIL PROTECTED] http://www.geoffthorpe.net/ __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: FQDN
There is no law that says the MITM must pass any traffic to any particular party. Yes there is. The law of definition of MITM If he can get plaintext out of A without sending anything ever to B, then he has won and he's still a man in the middle. The key is that he can intercept and control any traffic sent by one party to the protocol to any other party to the protocol. Those are worthwhile things, but they are intercepting, hijacking, etc. They are not a MITM attack. Yes, if you find out about him, he's still an adversary, but he is no longer a MITM. /r$ __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: FQDN
On Thu, Jul 24, 2003 at 03:43:43PM -0700, David Schwartz wrote: Please check this url: http://developer.netscape.com/docs/manuals/security/sslin/contents.htm Server authentication, step 4 The only difference is that netscape just check domain name. Does the domain name in the server's certificate match the domain name of the server itself? This step confirms that the server is actually located at the same network address specified by the domain name in the server certificate. Although step 4 is not technically part of the SSL protocol, it provides the only protection against a form of security attack known as a Man-in-the-Middle Attack. Clients must perform this step and must refuse to authenticate the server or establish a connection if the domain names don't match. If the server's actual domain name matches the domain name in the server certificate, the client goes on to Step 5. Technically, the TLS specification only cares about the cryptographical issues and the certificate verification from the cryptographical point of view as well as the certificate chain verification. This is however -- as pointed out -- not sufficient. At the end of the handshake and certificate verification it is only known, whether the peer could send a trustworthy certificate or not. The peer name check is required on a higher level, namely in the application specific protocol, e.g. in RFC2818: HTTP Over TLS, section 3: Endpoint Identity. In general, HTTP/TLS requests are generated by dereferencing a URI. As a consequence, the hostname for the server is known to the client. If the hostname is available, the client MUST check it against the server's identity as presented in the server's Certificate message, in order to prevent man-in-the-middle attacks. Other RFCs dealing with protocols using TLS contain respective formulations. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: FQDN
On 2003-07-24 at 18:43, David Schwartz wrote: Please check this url: http://developer.netscape.com/docs/manuals/security/sslin/contents.htm Server authentication, step 4 The only difference is that netscape just check domain name. Does the domain name in the server's certificate match the domain name of the server itself? This step confirms that the server is actually located at the same network address specified by the domain name in the server certificate. Although step 4 is not technically part of the SSL protocol, it provides the only protection against a form of security attack known as a Man-in-the-Middle Attack. Clients must perform this step and must refuse to authenticate the server or establish a connection if the domain names don't match. If the server's actual domain name matches the domain name in the server certificate, the client goes on to Step 5. As I suspected, you misunderstood it. This is NOT ABOUT DNS. This about confirming that the server's name (the name you think you're talking to) matches the name in the certificate. Well, if there is no DNS, how can you connect to a machine on the internet? If the DNS has been sabotaged, it won't lead you to the machine you want to connect. Yes, you will say that you still need to check DN, But even DNs match, it is still not enough for security. What's the difference between DN and FQDN? It is applciation related. If I'm sure that my application won't move from a machine to another, why can't I use FQDN? although it will limit application to a specific machine. Suppose I trust 'www.amazom.com'. I try to connect to 'www.amazon.com' and get 210.3.4.9. I am then a certificate for 'www.evilhost.com'. I compare the name of the server I am trying to speak to 'www.amazon.com' to the name in the certificate 'www.evilhost.com'. If they don't match, I refuse the connection. This is exactly what I was talking about. but not just this. In case you might misunderstand my question, I'd like to rephrase it here. Suppose I want to attack an online bank and managed to get the server's key (don't ask me why, i don't know either :-)). Through the certificate, I can know this key's DN (say domainA) or some extra information. Then I'll spoof DNS, make that domainA points to my machine. I'll preset a page to simulate a login screen on my machine. The clients will think that they are connecting to the real bank server, so I record their password, finally I can login to the real bank server after I restore DNS. This is what I'm trying to prevent. after shake-hand and authentication by SSL, it is still not safe enough. because other poople and I share some common secrets (key and certificate), but if secrets are comprised, (I know that people don't like this idea of losing key, but it happened before and will happen in the future) then I'm in trouble. My question is: can we find a solution to such a scenario? Such as application level authentication. Jacky As Netscape puts it, does the domain name in the server's certificate (www.evilhost.com in my example) match the domain name of the server itself (www.amazon.com in my example). In this case they don't. So the connection is refused (or, if you prefer, considered to be to/from 'www.evilhost.com' rather than 'www.amazon.com') regardless of what DNS says. Why I suppose someone can get clients' key? because in my case, my clients are people without computer background. I'd like to believe them know how to keep their keys. But in case keys are comprised, shouldn't we think about any possible solution to against it? I could spend months explaining why this is wrong. But I strongly advise you that you should take the word of the security experts who advise you that this argument makes no sense. I would cite as further evidence that you are in no position to maintain this claim against experts the fact that you misunderstand the basic machinations of how Netscape's server validation works. I'm not trying to be mean or rude. I'm just trying to stop you from doing something really, really bad. DS __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: FQDN
On Fri, Jul 25, 2003 at 09:18:52AM -0400, Jue (Jacky) Shu wrote: On 2003-07-24 at 18:43, David Schwartz wrote: Please check this url: http://developer.netscape.com/docs/manuals/security/sslin/contents.htm Server authentication, step 4 The only difference is that netscape just check domain name. Does the domain name in the server's certificate match the domain name of the server itself? This step confirms that the server is actually located at the same network address specified by the domain name in the server certificate. Although step 4 is not technically part of the SSL protocol, it provides the only protection against a form of security attack known as a Man-in-the-Middle Attack. Clients must perform this step and must refuse to authenticate the server or establish a connection if the domain names don't match. If the server's actual domain name matches the domain name in the server certificate, the client goes on to Step 5. As I suspected, you misunderstood it. This is NOT ABOUT DNS. This about confirming that the server's name (the name you think you're talking to) matches the name in the certificate. Well, if there is no DNS, how can you connect to a machine on the internet? If the DNS has been sabotaged, it won't lead you to the machine you want to connect. Yes, you will say that you still need to check DN, But even DNs match, it is still not enough for security. What's the difference between DN and FQDN? It is applciation related. If I'm sure that my application won't move from a machine to another, why can't I use FQDN? although it will limit application to a specific machine. Suppose I trust 'www.amazom.com'. I try to connect to 'www.amazon.com' and get 210.3.4.9. I am then a certificate for 'www.evilhost.com'. I compare the name of the server I am trying to speak to 'www.amazon.com' to the name in the certificate 'www.evilhost.com'. If they don't match, I refuse the connection. This is exactly what I was talking about. but not just this. In case you might misunderstand my question, I'd like to rephrase it here. Suppose I want to attack an online bank and managed to get the server's key (don't ask me why, i don't know either :-)). Through the certificate, I can know this key's DN (say domainA) or some extra information. Then I'll spoof DNS, make that domainA points to my machine. I'll preset a page to simulate a login screen on my machine. The clients will think that they are connecting to the real bank server, so I record their password, finally I can login to the real bank server after I restore DNS. This is what I'm trying to prevent. after shake-hand and authentication by SSL, it is still not safe enough. because other poople and I share some common secrets (key and certificate), but if secrets are comprised, I'd say own keys. Sharing them is a very bad idea. Please note certificates are sent in clear while SSL handshake so they should be considered public info (I know that people don't like this idea of losing key, but it happened before and will happen in the future) then I'm in trouble. My question is: can we find a solution to such a scenario? Such as application level authentication. Some more passwords and keys may be used at application level to hedge the risk and they can also be lost. That is, loosing any key makes a better chance to get in trouble and it happens sometime, isnt it? Please consider signed DNS (forward-type zone) in case you'd like to verify IP address Jacky As Netscape puts it, does the domain name in the server's certificate (www.evilhost.com in my example) match the domain name of the server itself (www.amazon.com in my example). In this case they don't. So the connection is refused (or, if you prefer, considered to be to/from 'www.evilhost.com' rather than 'www.amazon.com') regardless of what DNS says. Why I suppose someone can get clients' key? because in my case, my clients are people without computer background. I'd like to believe them know how to keep their keys. But in case keys are comprised, shouldn't we think about any possible solution to against it? I could spend months explaining why this is wrong. But I strongly advise you that you should take the word of the security experts who advise you that this argument makes no sense. I would cite as further evidence that you are in no position to maintain this claim against experts the fact that you misunderstand the basic machinations of how Netscape's server validation works. I'm not trying to be mean or rude. I'm just trying to stop you from doing something really, really bad. DS __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager
Re: FQDN
This is what I'm trying to prevent. after shake-hand and authentication by SSL, it is still not safe enough. because other poople and I share some common secrets (key and certificate), but if secrets are comprised, (I know that people don't like this idea of losing key, but it happened before and will happen in the future) then I'm in trouble. My question is: can we find a solution to such a scenario? Such as application level authentication. If the keys to my car are stolen, can I find a way to keep someone from driving it? 1) put an additional lock on the car ie add some application-level authentication. Of course, this is recursive - what if the bad guy gets these keys too? He got the first one, he can probably get the other ones too. 2) change the lock ie once you know someone stole your key, you generate a new one and have a CRL issued for the old one so it's no good any more. While you could add more and more #1 above to add security, the fact that they're getting any of your keys indicates you are doing a piss poor job of securing your machine and you're probably going to be building in application-level authentication poorly too. SSL relies on having everything about the algorithm public with the exception of one thing: the private keys. Deal with it - the private key must be private, or the game is lost. This is a definition, it cannot be changed. Security in depth is good, so feel free to layer on other controls if it makes you feel better. However if they got the key, then either they have access to your machine on which it resides thus they could simply query the data right from your database, insert a kernel module to capture all data, etc they were given the key by someone inside your organization thus if you change the key, they'll get that one too Protecting the private key is your most important task. Period. Doesn't this make sense? -- Brian Hatch It compiles! Systems andLet's ship it! Security Engineer -- the Microsoft motto http://www.ifokr.org/bri/ Every message PGP signed pgp0.pgp Description: PGP signature
Re: FQDN
David Schwartz wrote: This is not a MITM. A Man-in-the-middle attack assumes a party on the wire, witnessing all communication and able to insert arbitrary text. Exactly. That's a MITM. If I connect to 'www.amazon.com' through a MITM, that MITM can do one of two things. He can tamper with the certificate, replacing mine with his own, or he can pass my certificate. Without this check, a MITM could pass his own certificate, and handle both SSL conncetions (one to the server and one to the client) indepedently. He could then do whatever he wanted with the plaintext inbetween. You're terribly confused. The integrity of the cert is that it's cryptographically signed. A MITM cannot tamper with the cert. A MITM cannot perform the handshake unless he already has the private key associated with the public key bound to the identity in the cert. A MITM on the wire cannot tamper with the cert, cannot tamper with the handshake results without being detected, etc. SSL is proof against MITM when a server cert is presented. Otherwise, as I've explained twice now, a MITM from 'www.evilhost.com' could grab any connection to 'www.amazon.com' and present his own certificate. The certificate would seem valid. The certificate is valid, presumably. You have successfully authenticated www.evilhost.com and have established a secure connection to it. NOW what will you do? That's a matter of trust policy, which has nothing to do with MITM, nothing to do with SSL, etc. It happens to be a very practical thing that browsers do, and is the correct default behavior, to raise an alert when the cert presented doesn't match the FQDN. But it's your choice at that point. How am I protected against a MITM if I want to send my credit card to 'www.amazon.com' but the MITM redirects me to 'www.evilhost.com'? That's a redirect attack, a hijack, not MITM. The case of connecting to a different party (hijacking) has nothing whatsoever to do with MITM. A MITM is a different party! No offense, but do you have any idea what you're talking about? Back to school, David. MITM is used by cryptographers to refer to an interposer who is able to see all traffic on the wire and inject all traffic between two parties. SSL was specifically designed to be proof against MITM. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: FQDN
The case of connecting to a different party (hijacking) has nothing whatsoever to do with MITM. A MITM is a different party! No offense, but do you have any idea what you're talking about? Back to school, David. MITM is used by cryptographers to refer to an interposer who is able to see all traffic on the wire and inject all traffic between two parties. SSL was specifically designed to be proof against MITM. No, David is right. If I connect with SSL to a machine and get a successful SSL connection then it means I know that[1] no one can see what that machine and I are saying. I don't know that the machine to whom I'm talking is the one to whom I wished to talk. It could be anybody. Ahha! I know what we'll do, we'll require certificate authentication! Ok, assuming I have a list of the major CAs and the the certificate verified correctly I know that I'm talking to a machine that has a certificate trusted by one of my trusted CAs. I still have no proof that I successfully connected to www.example.org, I could have connected to www.evil_empire.com if it had a valid cert. (Signed by Verisign, etc) Shoot, I'm still not there, am I? What can I do to be sure I connected to www.example.org? I know, I'll check the CN? If the CN says 'www.example.org' and it was signed by a trusted CA above, then I can be sure[2] that I got the right host. If CN doesn't match, I know I got the wrong place. HTTPS uses not only certs and trusted CAs but the CN match test. If I use Stunnel for communication between just a few machines, perhaps I'll just use a few individual certs in hashed name format (.0 style) SSL doesn't say anything about CN checking. So, back to the comment: Back to school, David. MITM is used by cryptographers to refer to an interposer who is able to see all traffic on the wire and inject all traffic between two parties. SSL was specifically designed to be proof against MITM. Wrong. David's right. If a machine is able to get packets to go through him at any point, he can attempt to be a MITM. He doesn't need to know the keys on either endpoint if the endpoints don't verify them. He can talk SSL to both endpoints, and decrypt/encrypt between them using the two separate connections. Yes, this is a 100% valid definition of MITM. At least to us security/network folks. SSL was designed to *provide you the ability* to prevent MITM attacks, but you need to do all the checks above, it doesn't just happen by itself. I'm going to shut up now - this thread's gone on far too long with no illumination in sight. [1] Assuming no one has the server's private key [2] Assuming your CA is trustworthy, and that the private key wasn't compromised. -- Brian Hatch It compiles! Systems andLet's ship it! Security Engineer -- the Microsoft motto http://www.ifokr.org/bri/ Every message PGP signed pgp0.pgp Description: PGP signature
Re: FQDN
Brian Hatch wrote: Ahha! I know what we'll do, we'll require certificate authentication! Ok, assuming I have a list of the major CAs and the the certificate verified correctly You're missing the point. A hijack or redirect is not a MITM attack. These words have specific meaning, which you are abusing. Authentication != Authorization SSL doesn't say anything about CN checking. Right. Yes, this is a 100% valid definition of MITM. At least to us security/network folks. SSL was designed to *provide you the ability* to prevent MITM attacks, but you need to do all the checks above, it doesn't just happen by itself. You are simply mistaken. SSL is -IN SE- proof against MITM attack. It is computationally infeasible to succesfully interpose and perform the handshake between a client and a server in a non-anon setting. If you connect to and authenticate the wrong server, that's not a MITM. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: FQDN
Ahha! I know what we'll do, we'll require certificate authentication! Ok, assuming I have a list of the major CAs and the the certificate verified correctly You're missing the point. A hijack or redirect is not a MITM attack. These words have specific meaning, which you are abusing. No, I'm not. I promise you. Perhaps we're working from two different dictionaries, but the one I use (network security lingo) clearly does define that as one of the definitions. Think Dug Songs' dsniff (http://www.monkey.org/~dugsong/dsniff/ which provides MITM for ssh, https, etc. Authentication != Authorization Correct. Agreed. Yes, this is a 100% valid definition of MITM. At least to us security/network folks. SSL was designed to *provide you the ability* to prevent MITM attacks, but you need to do all the checks above, it doesn't just happen by itself. You are simply mistaken. SSL is -IN SE- proof against MITM attack. It is computationally infeasible to succesfully interpose and perform the handshake between a client and a server in a non-anon setting. If you connect to and authenticate the wrong server, that's not a MITM. Ok, let's take a vote. All who think this can be called MITM, please respond to /dev/null. Those who do not, please respond to /usr/../dev/null. So, what would you call it if someone interposes themselves in between you and the endpoint and you do not know that they are there? Is there not a generic term for it? Wouldn't that be oh never mind. I'm exiting this thread now. -- Brian Hatch Ouch! That's really painful. Systems and Reegen, 23 months, Edinburg, Security Engineer Scotland, 3am, as part of a http://www.ifokr.org/bri/ several hour long attempt to get out of her crib. Every message PGP signed pgp0.pgp Description: PGP signature
RE: FQDN
Brian Hatch wrote: Ahha! I know what we'll do, we'll require certificate authentication! Ok, assuming I have a list of the major CAs and the the certificate verified correctly You're missing the point. A hijack or redirect is not a MITM attack. These words have specific meaning, which you are abusing. Hijacks and redirects are all within the scope of what a MITM can do. You want a simple definition of a MITM? Here it is -- you think you have: server - network - client But under a MITM attack, you really have: server - MITM - client The MITM can do anything he wants from his position, including pass the data unmolested, drop bytes, or change them in both directions. Hijacking and redirection all occur on the wire between the server and the client, so they're all within the scope of a MITM attack. To put it simply, a MITM attack is any attack that can be performed by someone who has complete control over the network between the server and the client, that is, he is in the middle instead of a trusted network. If you think MITM means something else, please present your definition. I have a feeling you'll find it becomes incoherent. DS __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: FQDN
Hi, On July 25, 2003 01:45 pm, David Schwartz wrote: Hijacks and redirects are all within the scope of what a MITM can do. No, they only within the scope of what an attacker can do. The attacker becomes a MITM if they can do it without you knowing anything's wrong. Note doing it without you knowing anything's wrong means one of two things; one is to manipulate data in such a way that the end parties do not know that data has been changed (or created) in transit (authenticity), and the other is to be able to read the encapsulated data (secrecy). You want a simple definition of a MITM? Here it is -- you think you have: server - network - client But under a MITM attack, you really have: server - MITM - client The MITM can do anything he wants from his position, including pass the data unmolested, drop bytes, or change them in both directions. Hijacking and redirection all occur on the wire between the server and the client, so they're all within the scope of a MITM attack. To put it simply, a MITM attack is any attack that can be performed by someone who has complete control over the network between the server and the client, that is, he is in the middle instead of a trusted network. If you think MITM means something else, please present your definition. I have a feeling you'll find it becomes incoherent. Your definition is a waste of time, I'm sorry to say. What you're saying leads logically to the trivial extreme that any network protocol passing through the internet is vulnerable to MITM attacks. If you're happy with that definition then this email thread is without point. SSL/TLS never claims that it can prevent active traffic manipulation by undesirable parties, it just claims you'll know something's wrong when and if it happens and that all data passing through the SSL/TLS streams until that point will be both tamper-free and secret. Our definition of MITM is any attack that could passively or actively attack the communications such that you are none the wiser (or that you may have lost confidentiality or authenticity of data prior to knowing something was wrong). FWIW: there are limited MITM possibilities in SSLv2 that fit your definition *and* ours, but that's a different issue. It seems that you are defining your statement to be correct and working backwards from there. The one true MITM attack seems to be this enormous email thread - consisting of one side working from a sensible definition of MITM towards conclusions, and another working from an tautological conclusion backwards towards an unreasonable definition of MITM. Cheers, Geoff -- Geoff Thorpe [EMAIL PROTECTED] http://www.geoffthorpe.net/ __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: FQDN
David Schwartz wrote: Hijacks and redirects are all within the scope of what a MITM can do. That's a Humpty-Dumpty argument, not the definition used by cryptographers. You're simply confused, or are immune to education. You want a simple definition of a MITM? Here it is -- you think you have: Simple definitions are often wrong, as is yours. server - MITM - client The MITM can do anything he wants from his position, including pass the data unmolested, drop bytes, or change them in both directions. Hijacking and redirection all occur on the wire between the server and the client, so they're all within the scope of a MITM attack. No, mounting a MITM attack requires that the client be _unable to detect it_. The MITM cannot correctly negotiate the SSLv3 handshake, and cannot change bits without being detected. You had been describing a completely different attack, in which the endpoint of the SSL channel is a hostile party. Obviously, this could turn out badly. I'll repeat this -- SSLv3 was specifically designed to be proof against MITM attack. And it is. You can snoop all you want, you won't get the master shared secret and you won't be able to change bits in either direction without detection. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: FQDN
No, they only within the scope of what an attacker can do. The attacker becomes a MITM if they can do it without you knowing anything's wrong. And SSL/TLS does not itself let you know anything is wrong. SSL/TLS provides the *ability* for you to know something is wrong *if* the developers correctly used the tools available to them. Without enforcing certificate authentication and/or CN matching, the user will not know anything is wrong. This is a situation 100% possible in SSL/TLS implementations out there, and they are numerous. Hell, even Microsoft got it wrong when they failed to check certificate constraints, and I with an example.com cert could sign yahoo.com and be completely valid in the eyes of IE until it was patched. That was an example of SSL/TLS done wrong, that lead to the possibility of MITM attacks, period. Note doing it without you knowing anything's wrong means one of two things; one is to manipulate data in such a way that the end parties do not know that data has been changed (or created) in transit (authenticity), and the other is to be able to read the encapsulated data (secrecy). Agreed. Your definition is a waste of time, I'm sorry to say. What you're saying leads logically to the trivial extreme that any network protocol passing through the internet is vulnerable to MITM attacks. If you're happy with that definition then this email thread is without point. Yep, and he's right. With unencrypted/unauthenticated TCP, we admit that MITM is always a possibility, and isn't worth meantioning. If I telnet to some host with good old fashioned telnet, the router can sniff and/or modify my packets. Someone sitting with ethereal/hunt/etc can redirect things through their box. We just don't bother meantioning this vulnerability because it is guarenteed to be possible, and cannot be prevented. Yep, still a MITM, just not of interest. With SSL/TLS, however, the ability to do encryption and authentication should be able to prevent it. However, implementing SSL/TLS *correctly* is the only way to prevent it. If you do it right, then you'll get invalid certs or cn or other warnings. If you don't do it right, you don't know it happened. SSL/TLS never claims that it can prevent active traffic manipulation by undesirable parties, it just claims you'll know something's wrong when and if it happens and that all data passing through the SSL/TLS streams until that point will be both tamper-free and secret. No, SSL/TLS doesn't. I will continue to argue that it provides you the tools to do the above. It's done wrong all over the place. I don't want people to think that if they use SSL/TLS that they are secure, they are not unless the implementation is done well. My palm phone has an email app that only trusts a few CAs. I have a self signed cert on my server. I clicked the button 'always trust the remote cert'. I'm using TLS, yet I could still get no warning if there's a MITM attack.[1] If a closed source product were handed to you that says it supports SSL, would you stand up and say on a witness stand that it cannot be vulnerable to a MITM attack? Without knowing how it was written? For that matter, what about running 'stunnel -c -r www.example.com:443' ? That specifies no certificate sources and doesn't say to verify. It uses SSL - does that mean MITM attack is possible? What you've been saying above is that if something uses SSL, it is secure. I still say it must have SSL done *right* for it to be secure. All over the world, applications are being written by people with no crypto background, using third party libraries, who blindly piece together sample code until an SSL handshake completes successfully, and then they ship it. -- Brian Hatch When two egotists Systems andmeet, it's an I Security Engineer for an I. http://www.ifokr.org/bri/ Every message PGP signed pgp0.pgp Description: PGP signature
Re: FQDN
Sorry David, but your definition of MITM is wrong. Or, more accurately, it is not aligned with how cryptographers and security analysts generally conceive it. In an MITM attack, the adversary sits between A and B and is able to intercept and/or modify the communications between the two of them without their knowledge. Server certificates and the DN's CN must be the FQDN (sic:) help prevent MITM. (No, it doesn't happen automatically -- you have to check the trust chain, certificate keyUsage and nameConstraints, and all that other stuff -- but it is possible to write code that prevents MITM.) /r$ -- Rich Salz, Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: FQDN
In an MITM attack, the adversary sits between A and B and is able to intercept and/or modify the communications between the two of them without their knowledge. Server certificates and the DN's CN must be the FQDN (sic:) help prevent MITM. Yes, they help. They do a damned good job of it too. There are, of course, different ways you could do it -- you could have a copy of the peer's cert that you get from the remote party in a trusted manner (CEO brings you the key on a floppy, sent in a PGP signed email from a PGP key you already authenticated) and then not bother with the valid CA sig plus CN match, for example. But without *something*, the game is lost. (No, it doesn't happen automatically -- you have to check the trust chain, certificate keyUsage and nameConstraints, and all that other stuff -- but it is possible to write code that prevents MITM.) You made my point. It doesn't happen automatically. Thus someone saying that SSL/TLS is immune to MITM attacks is lying. SSL/TLS plus good authentication methods is immune to MITM attacks.[1] [1] Depending on everyone you trust being trustworthy. What if I'm a verisign employee and can manage to generate a verisign-signed cert for www.microsoft.com? I can MITM, and no alerts will occur until/unless they figure out what happened and revoke my certificate, which requires that CRL checking is available in the client application you're using. -- Brian Hatch Are you not the littlest Systems and bit pleased to see me? Security Engineer Oh my dear, perhaps even http://www.ifokr.org/bri/ less than that. Every message PGP signed pgp0.pgp Description: PGP signature
Re: FQDN
Hi, On July 25, 2003 03:13 pm, Brian Hatch wrote: SSL/TLS provides the *ability* for you to know something is wrong *if* the developers correctly used the tools available to them. Without enforcing certificate authentication and/or CN matching, the user will not know anything is wrong. This is a situation 100% possible in SSL/TLS implementations out there, and they are numerous. Hell, even Microsoft got it wrong when they failed to check certificate constraints, and I with an example.com cert could sign yahoo.com and be completely valid in the eyes of IE until it was patched. And this is precisely the crux of why I think this thread is a waste of bandwidth. Extremities and oddballs aside (NULL cipher-suites, etc), SSL/TLS provides authentication of at least one peer, potentially both. The SSL/TLS spec mentions key-exchange (read private key) and X509 (read public key). SSL/TLS does not stipulate a canonical mapping of certification verification to any arbitrary trust model - for precisely the reason that SSL/TLS does not stipulate what transport it runs over nor what use it is being put to. Talking about SSL/TLS not being resistent to MITM unless you check host names against certificate fields is pointless, because SSL/TLS is not restricted to running over a network with the concept of host names?! It appears David is trying to say that MITM applies against SSL/TLS because MITM applies against *HTTPS* if you don't apply some certificate checking *relevant* to HTTPS. Note HTTPS is not SSL/TLS, and vice versa. If I run SSL/TLS over unix domain sockets, it may be because I want secure IPC between applications in which case the certificate mapping may be to system users (or applications, services, whatever). How those identities are encoded in the certs is anyone's guess - perhaps it's email style. Where on earth do domain names fit into this scheme? They don't because they're not relevant to SSL/TLS. David's arguments are about HTTPS over TCP/IPv4, whereas SSL/TLS is about the abstract mechanics of providing secure communications over any reliable (but untrusted) transport. SSL/TLS gives you the X509 interface for deciding what trust/identity mappings apply, just as PKCS7 does - you have to take them up to the level of HTTPS (or S/MIME, respectively) before you get a chance to even make a sensible statement about what identity validation is. Which is where all this MITM (and you'll excuse me for a moment here) horse-shit seems to be coming from. With SSL/TLS, however, the ability to do encryption and authentication should be able to prevent it. However, implementing SSL/TLS *correctly* is the only way to prevent it. If you do it right, then you'll get invalid certs or cn or other warnings. If you don't do it right, you don't know it happened. This doesn't make sense. SSL/TLS is probably implemented correctly by loads of HTTPS clients that are wildly broken - HTTPS is what they've managed to get wrong. SSL/TLS gives you X509 as a means to apply a mapping from application x transport space to identity validation via X509. Do it however you want. SSL/TLS even defines the alerts and warnings to let you react appropriately if you don't like what you see. Why pollute the SSL/TLS specs with a bunch of layer-violating (again, excuse me) horse-shit to do with TCP/IPv4, web-browsers, or anything else? A perfectly validated (and Verisign-signed) certificate calling itself www.amazon.com will be absolutely no use to me if I'm program X trying to establish secure IPC comms with program Y relative to my own IPC-specific certificate expectations and my own approved CA-list. I don't need SSL/TLS giving me square pegs to put in round holes, thank you very much. If a closed source product were handed to you that says it supports SSL, would you stand up and say on a witness stand that it cannot be vulnerable to a MITM attack? Without knowing how it was written? This is seriously mixing up issues. The first is that supporting a protocol does not imply you haven't made a mistake. Orthogonally to that is a second, MITM is something you can protect against at the operational level only provided you define what it *means* at the operational level, and SSL/TLS is what you do underneath that. If Microsoft tells me that outlook express supports PKCS7, does that mean I should feel good when it authenticates email signatures and green-lights the results? No, because PKCS7 is not (quite) S/MIME. SSL/TLS is also, not (quite) HTTPS. You need to go a layer (or more) up from SSL/TLS before you have any space in which to make *sense* of identity, and thus to define what a MITM threat is. What David appears to be saying, however, is either (i) that SSL/TLS itself is vulnerable to MITM no matter what you do at the operational level (which is wrong), or (ii) that SSL/TLS is vulnerable to MITM because it doesn't define the operational (or instantiation) level
Re: FQDN
And this is precisely the crux of why I think this thread is a waste of bandwidth. Agreed. I'll end, promising to shut up after this, with the following summary 1) SSL/TLS has the capabilities to be immune to MITM attacks. 2) These capabilities may be used in any number of ways, as determined by the needs of the system (unix domain sockets could rely soley on file permissions, and forgo any need for X509/etc) or the protocol specification (HTTPS requirement for trusted CAs and thus prevent an attack by requiring CN match.) 3) Not using sufficent SSL/TLS capabilities in a secure way can leave SSL/TLS open to successful attacks.[1] 4) Lots of companies/products probably do #3 above 5) No matter who replies to this message, I promise to not respond to the list, and I hope not to respond off the list either. [1] Yes, we all dissagree with the definition of 'MITM', which is why I just called this 'attacks'. -- Brian Hatch Look, somebody's got to have Systems andsome damn perspective around Security Engineer here. Boom, sooner or later. http://www.ifokr.org/bri/ *BOOM*! Every message PGP signed pgp0.pgp Description: PGP signature
RE: FQDN
David Schwartz wrote: Hijacks and redirects are all within the scope of what a MITM can do. That's a Humpty-Dumpty argument, not the definition used by cryptographers. You're simply confused, or are immune to education. No, I am not at all confused. You are confused and immune to education and based on the number of emails I've gotten about this thread from professional security people, I'm pretty sure I'm right. You want a simple definition of a MITM? Here it is -- you think you have: Simple definitions are often wrong, as is yours. server - MITM - client The MITM can do anything he wants from his position, including pass the data unmolested, drop bytes, or change them in both directions. Hijacking and redirection all occur on the wire between the server and the client, so they're all within the scope of a MITM attack. No, mounting a MITM attack requires that the client be _unable to detect it_. The MITM cannot correctly negotiate the SSLv3 handshake, and cannot change bits without being detected. No. Mounting a MITM attack requires nothing at all except the ability to intercept and modify network traffic. Mounting a *successful* MITM attack requires that you either obtain some of the plaintext *or* convince the client that some data came from the server when it really didn't. You had been describing a completely different attack, in which the endpoint of the SSL channel is a hostile party. Obviously, this could turn out badly. That's a MITM attack. One of the things a MITM can do is be the endpoint for two separate SSL connections rather than the one from server to client that you think you have. That's a classic MITM attack. I'll repeat this -- SSLv3 was specifically designed to be proof against MITM attack. And it is. You can snoop all you want, you won't get the master shared secret and you won't be able to change bits in either direction without detection. The MITM can run separate SSL sessions to both the server and the client and proxy the plaintext between the two connections. That's well within the scope of what a MITM can do. SSLv3 only provides protection against a MITM attack if one of two things is the case: 1) The end that cares about authentication (the client for HTTPS) compares the name in the certificate against the name of the server it wants to talk to, OR 2) Only trusted parties have access to certificates signed by any CA the end that cares about authentication trusts. The Internet security model employs option 1. Without it, there would be no protection whatsoever from a MITM who closes both SSL sessions and proxies the plaintext. Lest anyone thinks I'm making this up, I'll offer the following links all of which support my definition that a MITM attack occurs when the attacker has total control over the network: http://www.wordspy.com/words/maninthemiddleattack.asp A computer security breach in which a malicious user intercepts - and possibly alters - data traveling along a network. (Also: man-in-the-middle attack.) Backgrounder: This exploit also goes by the name TCP hijacking (where TCP is a method by which data is transmitted across a network). http://www.wikipedia.org/wiki/Man_in_the_middle In cryptography, the man in the middle attack is an attack where the attacker is able to read, and possibly modify at will, messages between two parties without letting either party know that they have been attacked. The attacker must be able to observe and intercept messages going between the two victims. With public keys an attack might look as follows: Adam wishes to communicate with Betsy. Edith wishes to eavesdrop on the conversation, or possibly deliver a false message to Betsy. Adam will ask Betsy for her public key. Betsy will send her public key to Adam, but Edith will intercept it, and send Adam her own public key. Adam then encrypts his message with Edith's key (which he believes is Betsy's) and sends it back to Betsy. Edith again intercepts, decrypts the message and reads the contents. She then encrypts the message (altered if she so desires) with Betsy's key and sends it on to Betsy, who believes she has received it directly from Adam. A similar principle can apply to packets transmitted using any public key technology. http://www.vandyke.com/solutions/ssh_overview/ssh_overview_threats.html Man-in-the-Middle Attack (MITM) If the first connection and host key exchange between a client and a particular host is compromised, the MITM attack fools both the client and server into thinking that they are communicating directly with one another when, in fact, an attacker is actually intercepting all traffic between the two as illustrated below: In a MITM attack an attacker (Eve) impersonates both the server and the client. The client (Bob) initiates a connection with the server (Alice). Unknown to both Bob and Alice, an attacker
RE: FQDN
Hi, On July 25, 2003 01:45 pm, David Schwartz wrote: Hijacks and redirects are all within the scope of what a MITM can do. No, they only within the scope of what an attacker can do. The attacker becomes a MITM if they can do it without you knowing anything's wrong. The MITM attack is successful if either he intercepts any of the plain text or he manages to convince the client that some data came from the server when it really did not. Note doing it without you knowing anything's wrong means one of two things; one is to manipulate data in such a way that the end parties do not know that data has been changed (or created) in transit (authenticity), and the other is to be able to read the encapsulated data (secrecy). Exactly. You want a simple definition of a MITM? Here it is -- you think you have: server - network - client But under a MITM attack, you really have: server - MITM - client The MITM can do anything he wants from his position, including pass the data unmolested, drop bytes, or change them in both directions. Hijacking and redirection all occur on the wire between the server and the client, so they're all within the scope of a MITM attack. To put it simply, a MITM attack is any attack that can be performed by someone who has complete control over the network between the server and the client, that is, he is in the middle instead of a trusted network. If you think MITM means something else, please present your definition. I have a feeling you'll find it becomes incoherent. Your definition is a waste of time, I'm sorry to say. What you're saying leads logically to the trivial extreme that any network protocol passing through the internet is vulnerable to MITM attacks. If you're happy with that definition then this email thread is without point. Not at all. SSL with comparison of the certificate name to name of the intended recipient is invulnerable to MITM attacks. All a MITM can do is prevent data from being exchanged. (And, of course, a MITM can always do that.) You are playing games with the word vulnerable. Yes, any Internet protocol is vulnerable to a MITM attack in the sense that a MITM can deny service. But we know that, and we live with that vulnerability. We would, however, be upset with any cryptographic protocol where a MITM attack could result in plaintext being compromised. SSL/TLS never claims that it can prevent active traffic manipulation by undesirable parties, it just claims you'll know something's wrong when and if it happens and that all data passing through the SSL/TLS streams until that point will be both tamper-free and secret. How will you know something's wrong if you don't compare the name in the certificate to the name of the server you intended to speak to? That's not part of SSL/TLS. SSL/TLS itself is vulnerable to plaintext compromise from a MITM attack unless you confirm the certificate in some way. Our definition of MITM is any attack that could passively or actively attack the communications such that you are none the wiser (or that you may have lost confidentiality or authenticity of data prior to knowing something was wrong). I'm sorry, what good is it if I know that a theif got my credit card information when I tried to send it to 'www.amazon.com'? All that matters for a successful MITM attack is that either the MITM obtains some of the plaintext or fools the client into thinking some data came from a trusted party when it didn't. A MITM can deny service. A MITM can make himself known. A MITM can fail to obtain any plaintext. All of these things are within the scope of what a MITM can do, they just might fail to make successful attacks. FWIW: there are limited MITM possibilities in SSLv2 that fit your definition *and* ours, but that's a different issue. It seems that you are defining your statement to be correct and working backwards from there. The one true MITM attack seems to be this enormous email thread - consisting of one side working from a sensible definition of MITM towards conclusions, and another working from an tautological conclusion backwards towards an unreasonable definition of MITM. I'm amazed that you would disagree with every published definition of a MITM I could find. DS __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: FQDN
David Schwartz wrote: No, I am not at all confused. You are confused and immune to education and based on the number of emails I've gotten about this thread from professional security people, I'm pretty sure I'm right David, I am a security professional, and I have the greatest respect for Rich Salz, and I have the greatest confidence in Geoff Thorpe as well. The MITM can run separate SSL sessions to both the server and the client and proxy the plaintext between the two connections. That's well within the scope of what a MITM can do. That's not MITM against SSL, is it? Trust != Authentication. Since we're talking about a definition, it's impossible for everybody else to be wrong and for you to be right. I'm happy with the company I'm in on the issue, thanks. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: FQDN
Sorry David, but your definition of MITM is wrong. Or, more accurately, it is not aligned with how cryptographers and security analysts generally conceive it. I don't see how. I just went to 35 sites that defined MITM and all of them defined them the way I did. In an MITM attack, the adversary sits between A and B and is able to intercept and/or modify the communications between the two of them without their knowledge. Right. That is, they don't automatically know he's there. They might be able to detected he's there from the data, but they aren't provided some out-of-band there's a MITM there signal. (Otherwise no protocol would be vulnerable to MITM, just don't send anything if there's a MITM.) If you can determine there's a MITM before you've send any sensitive data, the MITM attack fails. If the MITM can obtain some plaintext before you could detect him, he wins. Server certificates and the DN's CN must be the FQDN (sic:) help prevent MITM. (No, it doesn't happen automatically -- you have to check the trust chain, certificate keyUsage and nameConstraints, and all that other stuff -- but it is possible to write code that prevents MITM.) Exactly. SSL itself doesn't protect you against a MITM attack though it provides you with all the tools to provide such protection. Just knowing that a product uses SSL, you would have no way to know whether it was vulnerable to a MITM attack or not. I still don't understand where you're disagreeing with me. My definition of a MITM seems to be the same as yours. A MITM is an attacker who has complete control over the network between the client and server, unbeknownst to either of us. A successful MITM attack is one in which a MITM obtains access to some of the plaintext. (This is slightly simplified.) DS __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: FQDN
SSL/TLS plus good authentication methods is immune to MITM attacks.[1] [1] Depending on everyone you trust being trustworthy. What if I'm a verisign employee and can manage to generate a verisign-signed cert for www.microsoft.com? I can MITM, and no alerts will occur until/unless they figure out what happened and revoke my certificate, which requires that CRL checking is available in the client application you're using. You can score a technical victory over this MITM attack just by saying that if you choose to trust a Verisign cert, Verisign is an intended recipient of the communication. A MITM is not permitted access to anything known only to intended recipients, and that would include Verisign's private key. However, most people don't like to think of Verisign as the intended recipient to all of their HTTPS communication. But technically, if you choose to trust Verisign certificates, you must either consider Verisign an intended recipient or you're technically vulnerable to a MITM attack where the MITM obtains a certificate with the intended server's name in it. How practical this attack is -- that's another story. Presumably, the reason you trust Verisign is because such an attack is highly impractical. DS __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: FQDN
No, I am not at all confused. You are confused and immune to education and based on the number of emails I've gotten about this thread from professional security people, I'm pretty sure I'm right David, I am a security professional, and I have the greatest respect for Rich Salz, and I have the greatest confidence in Geoff Thorpe as well. Just so no one misinterprets the purpose or tone of my previous emails, I also have the greatest respect for Rich and Geoff. This thread began with questions by a programmer whom we all seemed to believe had a fundamental lack of understanding about crypto and SSL/TLS. Somehow that turned into a discussion about the definition of MITM with respect to SSL/TLS. All the participents since I joined the fray have said the same things, regardless of their viewpoint on the definition of MITM. The emails written by Rich, Geoff, David, and I have agreed on the facts of what SSL/TLS can do, what security (x509 usage) it offers and when it fails. It's only the definition of MITM in which we've divided into separate camps. Let's all agree to dissagree on this point. Truce. I'm going to bed. -- Brian Hatch But it's a dry heat. Systems and Turn on your oven. Climb Security Engineer inside. Yeah, that's a dry http://www.ifokr.org/bri/ heat too, but you're still going to bake, my friend. Every message PGP signed pgp0.pgp Description: PGP signature
RE: FQDN
Please check this url: http://developer.netscape.com/docs/manuals/security/sslin/contents.htm Server authentication, step 4 The only difference is that netscape just check domain name. Does the domain name in the server's certificate match the domain name of the server itself? This step confirms that the server is actually located at the same network address specified by the domain name in the server certificate. Although step 4 is not technically part of the SSL protocol, it provides the only protection against a form of security attack known as a Man-in-the-Middle Attack. Clients must perform this step and must refuse to authenticate the server or establish a connection if the domain names don't match. If the server's actual domain name matches the domain name in the server certificate, the client goes on to Step 5. As I suspected, you misunderstood it. This is NOT ABOUT DNS. This about confirming that the server's name (the name you think you're talking to) matches the name in the certificate. Suppose I trust 'www.amazom.com'. I try to connect to 'www.amazon.com' and get 210.3.4.9. I am then a certificate for 'www.evilhost.com'. I compare the name of the server I am trying to speak to 'www.amazon.com' to the name in the certificate 'www.evilhost.com'. If they don't match, I refuse the connection. As Netscape puts it, does the domain name in the server's certificate (www.evilhost.com in my example) match the domain name of the server itself (www.amazon.com in my example). In this case they don't. So the connection is refused (or, if you prefer, considered to be to/from 'www.evilhost.com' rather than 'www.amazon.com') regardless of what DNS says. Why I suppose someone can get clients' key? because in my case, my clients are people without computer background. I'd like to believe them know how to keep their keys. But in case keys are comprised, shouldn't we think about any possible solution to against it? I could spend months explaining why this is wrong. But I strongly advise you that you should take the word of the security experts who advise you that this argument makes no sense. I would cite as further evidence that you are in no position to maintain this claim against experts the fact that you misunderstand the basic machinations of how Netscape's server validation works. I'm not trying to be mean or rude. I'm just trying to stop you from doing something really, really bad. DS __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: FQDN
David Schwartz wrote: Does the domain name in the server's certificate match the domain name of the server itself? This step confirms that the server is actually located at the same network address specified by the domain name in the server certificate. Although step 4 is not technically part of the SSL protocol, it provides the only protection against a form of security attack known as a Man-in-the-Middle Attack. Clients must perform this step and must refuse to authenticate the server or establish a connection if the domain names don't match. If the server's actual domain name matches the domain name in the server certificate, the client goes on to Step 5. Uh, I'm a wee bit annoyed at the invocation of MITM. It seems to me that SSLv3.0/TLSv1.0 with server auth protects against MITM, and it has nothing to do with the validation described. We know at the conclusion of the handshake that we are talking to the server which presented its certificate, and we presume (absent its inclusion in a CRL, OCSP response, etc.) the security of the associated private key. This entire negotiation is proof against MITM. We've validated the cert according to local rules (we trust the signer, have done chain validation, whatever). Fine, all SSL/TLS does is establish a secure channel between (in this case) the authenticated server and the client. Trust management is entirely outside the scope of the protocol. This has nothing to do with MITM. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: FQDN
David Schwartz wrote: Does the domain name in the server's certificate match the domain name of the server itself? This step confirms that the server is actually located at the same network address specified by the domain name in the server certificate. Although step 4 is not technically part of the SSL protocol, it provides the only protection against a form of security attack known as a Man-in-the-Middle Attack. Clients must perform this step and must refuse to authenticate the server or establish a connection if the domain names don't match. If the server's actual domain name matches the domain name in the server certificate, the client goes on to Step 5. Uh, I'm a wee bit annoyed at the invocation of MITM. It seems to me that SSLv3.0/TLSv1.0 with server auth protects against MITM, and it has nothing to do with the validation described. What? it's this authentication that protects against a MITM. We know at the conclusion of the handshake that we are talking to the server which presented its certificate, and we presume (absent its inclusion in a CRL, OCSP response, etc.) the security of the associated private key. This entire negotiation is proof against MITM. We've validated the cert according to local rules (we trust the signer, have done chain validation, whatever). Huh?! If I ask for 'www.amazon.com', I don't care whether I have a secure or insecure connection to 'www.microsoft.com' or 'www.evil-mitms.com'. I care that the certificate I got doesn't match the server I chose to trust. A MITM can get a certificate for something. Fine, all SSL/TLS does is establish a secure channel between (in this case) the authenticated server and the client. Yes, that's all SSL/TLS does. This check is not formally part of SSL (which the quotation above makes clear). Without it, howerver, SSL would present no protection against a MITM who had a vaild certificate. Trust management is entirely outside the scope of the protocol. This has nothing to do with MITM. That's where your wrong. In the Internet trust model (anyone can get a certificate signed by a trusted authority, all the certificate does it prove they are who they say they are, not that they're someone I can trust), this *is* the protection against a MITM. If I try to connect to 'www.amazon.com', a MITM can do one of two things: 1) He can present the cert for 'www.amazon.com', but in that case, since he doesn't have the private key, he can neither decrypt nor modify the data. 2) He can present his own cert for 'www.evil-mitms.com', but in that case, I'll just dump the connection by this exact check. So it's this check the stops MITM in the Internet's security model. It is different in the NSA's security model, where you might be willing to trust anyone who had an NSA-signed certificate regardless of contents, or where you can trust the certificate to tell you what privileges to give. That's why this isn't part of SSL (as you and Netscape correctly note). DS __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: FQDN
David Schwartz wrote: That's where your wrong. In the Internet trust model (anyone can get a certificate signed by a trusted authority, all the certificate does it prove they are who they say they are, not that they're someone I can trust), this *is* the protection against a MITM. This is not a MITM. A Man-in-the-middle attack assumes a party on the wire, witnessing all communication and able to insert arbitrary text. SSL guards against this in the case where the server (and, optionally, the client) are authenticated. The case of connecting to a different party (hijacking) has nothing whatsoever to do with MITM. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: FQDN
David Schwartz wrote: That's where your wrong. In the Internet trust model (anyone can get a certificate signed by a trusted authority, all the certificate does it prove they are who they say they are, not that they're someone I can trust), this *is* the protection against a MITM. This is not a MITM. A Man-in-the-middle attack assumes a party on the wire, witnessing all communication and able to insert arbitrary text. Exactly. That's a MITM. If I connect to 'www.amazon.com' through a MITM, that MITM can do one of two things. He can tamper with the certificate, replacing mine with his own, or he can pass my certificate. Without this check, a MITM could pass his own certificate, and handle both SSL conncetions (one to the server and one to the client) indepedently. He could then do whatever he wanted with the plaintext inbetween. It is precisely this check that defeats the MITM. If the MITM passes the certificate unmolested, he can neither decode nor modify the plaintext. If the MITM molests the certificate, this is the check that will reject the connection. Otherwise, as I've explained twice now, a MITM from 'www.evilhost.com' could grab any connection to 'www.amazon.com' and present his own certificate. The certificate would seem valid. He could then himself connect to 'www.amazon.com' and pass the plaintext, free to decode and manipulate it. In the Internet's security model, this IS the defense against a MITM. SSL guards against this in the case where the server (and, optionally, the client) are authenticated. NO, IT DOENS'T! How am I protected against a MITM if I want to send my credit card to 'www.amazon.com' but the MITM redirects me to 'www.evilhost.com'? The 'www.evilhost.com' server can present me authentication -- they can get a Verisign certificate as easily as anyone. It is the check between the name in the certificate and the name of the server (NOT THE DNS NAME) that defends against a MITM. The case of connecting to a different party (hijacking) has nothing whatsoever to do with MITM. A MITM is a different party! No offense, but do you have any idea what you're talking about? DS __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: FQDN
Hi, I'm a newcomer to this crypto business and maybe I'm a little confused... I don't want to hijack this conversation but surely somebody from evil.bar.com could provide a certificate signed by a trusted party for example.foo.com. After all, the certificate is public right? So something else, be it DNS related or otherwise, must be needed to make sure the connection is sound. Is it not common practice to do a test encryption, thereby ensuring the 'other end' has a private key to match the public key in the certificate? Again, apologies for interrupting but I am now quite confused, Dan -Original Message- From: David Schwartz [mailto:[EMAIL PROTECTED] Sent: 23 July 2003 02:55 To: [EMAIL PROTECTED] Subject: RE: FQDN Thank you, David and Steve. Yes, it will be a big problem if someone spoof DNS, but it can prevent man-in-the-middle to some extent. No, it cannot. If the DNS is sabotaged, what can we do? What should I believe? :-) You should ignore the DNS entirely. If you receive a certificate signed by a trusted authority, you can believe that you are talking to the entity whose name appears in that certificate. All a man-in-the-middle can do in that case is break the connection. I don't understand why you care about DNS at all. If you receive a certificate with a common name of 'foo.example.com', you are talking to 'foo.example.com', period. It doesn't matter what IP address you connected to, connect to you, or what it resolves or doesn't resolve to. DS __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: FQDN
On Wed, Jul 23, 2003, Dan Kendall wrote: Hi, I'm a newcomer to this crypto business and maybe I'm a little confused... I don't want to hijack this conversation but surely somebody from evil.bar.com could provide a certificate signed by a trusted party for example.foo.com. After all, the certificate is public right? So something else, be it DNS related or otherwise, must be needed to make sure the connection is sound. Is it not common practice to do a test encryption, thereby ensuring the 'other end' has a private key to match the public key in the certificate? Again, apologies for interrupting but I am now quite confused, The way the SSL/TLS handshake works means that it will fail if the server does not have access to the private key corresponding to the certificate it claims to be its own. In one case the client send some data (the premaster secret) encrypted using the servers certified public key and both sides derive various session keys based on it. If the server cannot decrypt this data it can't derive the session keys and the handshake fails. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED], PGP key: via homepage. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: FQDN
On Wed, Jul 23, 2003 at 01:28:36PM +0100, Dan Kendall wrote: I'm a newcomer to this crypto business and maybe I'm a little confused... I don't want to hijack this conversation but surely somebody from evil.bar.com could provide a certificate signed by a trusted party for example.foo.com. After all, the certificate is public right? So something else, be it DNS related or otherwise, must be needed to make sure the connection is sound. Is it not common practice to do a test encryption, thereby ensuring the 'other end' has a private key to match the public key in the certificate? This is an elementary part of the protocol. Your party will send its certificate _and_ will cryptographically sign it with the private key. Therefore only the holder of the private key will be able to use the public key being part of the certificate. Again: DNS is not secure. Therefore the standards (RFCs) describing the use of TLS for certain protocols insist on: 1 choose a peer and remember its NAME 2 look up the peer in DNS, if required to establish the connection 3 perform the TLS handshake and obtain the peer's certificate 4 check validity of the certificate (expiry, CA, ...) 5 check whether the subject certified is identical to NAME Point 2 (DNS lookup) is only an auxilliary step required due to the network protocol used. It does not have any security implications beyond the fact that it is not trustworthy. The security comes from step 5. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: FQDN
Thank you, that makes more sense. Regards, Dan -Original Message- From: Lutz Jaenicke [mailto:[EMAIL PROTECTED] Sent: 23 July 2003 13:44 To: [EMAIL PROTECTED] Subject: Re: FQDN On Wed, Jul 23, 2003 at 01:28:36PM +0100, Dan Kendall wrote: I'm a newcomer to this crypto business and maybe I'm a little confused... I don't want to hijack this conversation but surely somebody from evil.bar.com could provide a certificate signed by a trusted party for example.foo.com. After all, the certificate is public right? So something else, be it DNS related or otherwise, must be needed to make sure the connection is sound. Is it not common practice to do a test encryption, thereby ensuring the 'other end' has a private key to match the public key in the certificate? This is an elementary part of the protocol. Your party will send its certificate _and_ will cryptographically sign it with the private key. Therefore only the holder of the private key will be able to use the public key being part of the certificate. Again: DNS is not secure. Therefore the standards (RFCs) describing the use of TLS for certain protocols insist on: 1 choose a peer and remember its NAME 2 look up the peer in DNS, if required to establish the connection 3 perform the TLS handshake and obtain the peer's certificate 4 check validity of the certificate (expiry, CA, ...) 5 check whether the subject certified is identical to NAME Point 2 (DNS lookup) is only an auxilliary step required due to the network protocol used. It does not have any security implications beyond the fact that it is not trustworthy. The security comes from step 5. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: FQDN
Yes, Lutz. That's why I want to check peer's FQDN against which on its certificate. Actually, just like what Steve said before, even the hacker can spoof DNS, he still needs peer's certificates and key to masquerade the owner of that key. Checking of the FQDN is an extra step to prevent this to happen. Jacky - Original Message - From: Lutz Jaenicke [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 23, 2003 8:43 AM Subject: Re: FQDN On Wed, Jul 23, 2003 at 01:28:36PM +0100, Dan Kendall wrote: I'm a newcomer to this crypto business and maybe I'm a little confused... I don't want to hijack this conversation but surely somebody from evil.bar.com could provide a certificate signed by a trusted party for example.foo.com. After all, the certificate is public right? So something else, be it DNS related or otherwise, must be needed to make sure the connection is sound. Is it not common practice to do a test encryption, thereby ensuring the 'other end' has a private key to match the public key in the certificate? This is an elementary part of the protocol. Your party will send its certificate _and_ will cryptographically sign it with the private key. Therefore only the holder of the private key will be able to use the public key being part of the certificate. Again: DNS is not secure. Therefore the standards (RFCs) describing the use of TLS for certain protocols insist on: 1 choose a peer and remember its NAME 2 look up the peer in DNS, if required to establish the connection 3 perform the TLS handshake and obtain the peer's certificate 4 check validity of the certificate (expiry, CA, ...) 5 check whether the subject certified is identical to NAME Point 2 (DNS lookup) is only an auxilliary step required due to the network protocol used. It does not have any security implications beyond the fact that it is not trustworthy. The security comes from step 5. Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: FQDN
Jue (Jacky) Shu wrote: Yes, Lutz. That's why I want to check peer's FQDN against which on its certificate. Look at Lutz' list. You get already in step 1 the FQDN from the *user*, so there is no need for further actions to find out the peer's FQDN. Ciao, Richard -- Dr. Richard W. Könning Fujitsu Siemens Computers GmbH, EP LP COM 5 __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: FQDN
Sorry, Richard. Maybe I didn't put it clearly. There r two names, one is from the certificate, another one is from DNS. They must match. Jacky - Original Message - From: Richard Koenning [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 23, 2003 9:43 AM Subject: Re: FQDN Jue (Jacky) Shu wrote: Yes, Lutz. That's why I want to check peer's FQDN against which on its certificate. Look at Lutz' list. You get already in step 1 the FQDN from the *user*, so there is no need for further actions to find out the peer's FQDN. Ciao, Richard -- Dr. Richard W. Könning Fujitsu Siemens Computers GmbH, EP LP COM 5 __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: FQDN
Jue (Jacky) Shu wrote: Sorry, Richard. Maybe I didn't put it clearly. There r two names, one is from the certificate, another one is from DNS. They must match. The other one is *not* from DNS, but from the *user* (step 1 from Lutz' list). The user wants to connect to a specific site, and the system has to ensure that it does, what the *user* wants. Therefore, get the FQDN from the *user* and ensure that the name from the certificate agrees with the FQDN from the *user*. Ciao, Richard -- Dr. Richard W. Könning Fujitsu Siemens Computers GmbH, EP LP COM 5 __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: FQDN
Hi Richard, In your case, it is the client want to check server. I know it is common to check server's location. But now I want to check client as well. The server doesn't know where the client comes from, so the server needs to get client's ip address and then its FQDN. I think this problem is security model related. If your client's location is very flexible, from one domain to another, then we can't check it based where it is from. In this case, maybe u can create a list for the client's legtimate locations. Ciao Jacky - Original Message - From: Richard Koenning [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 23, 2003 10:20 AM Subject: Re: FQDN Jue (Jacky) Shu wrote: Sorry, Richard. Maybe I didn't put it clearly. There r two names, one is from the certificate, another one is from DNS. They must match. The other one is *not* from DNS, but from the *user* (step 1 from Lutz' list). The user wants to connect to a specific site, and the system has to ensure that it does, what the *user* wants. Therefore, get the FQDN from the *user* and ensure that the name from the certificate agrees with the FQDN from the *user*. Ciao, Richard -- Dr. Richard W. Könning Fujitsu Siemens Computers GmbH, EP LP COM 5 __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: FQDN
On Tue, Jul 22, 2003, Jue (Jacky) Shu wrote: Thank you, David and Steve. Yes, it will be a big problem if someone spoof DNS, but it can prevent man-in-the-middle to some extent. If an attacker can do MITM they can readily spoof DNS as well. If the DNS is sabotaged, what can we do? What should I believe? :-) Well you have to do the unusual step of trusting the user :-) If they say that they want to connect to www.foobar.inc you assume that that's what they want to do. If however you go through various DNS contortions to get the final hostname then DNS spoofing would make it unreliable. It all depends on your threat model and trust policy. AFAICS in your scenario a MITM can only occur if the attacker has access to a trusted certificate and private key. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED], PGP key: via homepage. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: FQDN
Yes, it will be a big problem if someone spoof DNS, but it can prevent man-in-the-middle to some extent. If the DNS is sabotaged, what can we do? What should I believe? :-) The point is that if you trust the user -- you should, after all you are doing what they requested you to do -- than you don't have to trust DNS and, in fact, can tell if it's been compromised. Doesn't get any better than that. /r$ __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: FQDN
Thank you, David and Steve. Yes, it will be a big problem if someone spoof DNS, but it can prevent man-in-the-middle to some extent. No, it cannot. If the DNS is sabotaged, what can we do? What should I believe? :-) You should ignore the DNS entirely. If you receive a certificate signed by a trusted authority, you can believe that you are talking to the entity whose name appears in that certificate. All a man-in-the-middle can do in that case is break the connection. I don't understand why you care about DNS at all. If you receive a certificate with a common name of 'foo.example.com', you are talking to 'foo.example.com', period. It doesn't matter what IP address you connected to, connect to you, or what it resolves or doesn't resolve to. DS __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: FQDN
There is no functino in OpenSSL I beleive that does such a thing. What you need to do is get the sockaddr sin_addr data from the accept() function. At that point you have a IP Address. Use gethostbyaddr() to convert that IP into a FQDN. You can then verify that the FQDN of the host matches that in the certificate. On Mon, Jul 21, 2003 at 12:12:49PM -0400, Jue (Jacky) Shu wrote: hi all, maybe it is not a SSL question. I want to make post-connection assertion to prevent man-in-the-middle attack. But I don't know how to get FQDN of the peer side(Not from peer's certificate, it must be other side's real address). Is there any socket fucntion to get peer's FQDN? thank you in advance. Jacky __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: FQDN
On Mon, Jul 21, 2003 at 12:12:49PM -0400, Jue (Jacky) Shu wrote: hi all, maybe it is not a SSL question. I want to make post-connection assertion to prevent man-in-the-middle attack. But I don't know how to get FQDN of the peer side(Not from peer's certificate, it must be other side's real address). Is there any socket fucntion to get peer's FQDN? thank you in advance. Jacky this makes sense for a client connecting to some server. The client use some FQDN (user input? configuration file?) to pass it to DNS and do connect() to the host. So the client could check whether the host respond with that FQDN as the common name of server certificate. hope this helps, Vadim __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: FQDN
On Mon, Jul 21, 2003 at 12:20:05PM -0400, Christopher Fowler wrote: There is no functino in OpenSSL I beleive that does such a thing. What you need to do is get the sockaddr sin_addr data from the accept() function. At that point you have a IP Address. Use gethostbyaddr() to convert that IP into a FQDN. You can then verify that the FQDN of the host matches that in the certificate. I doubt this. Yes, DNS is used for lookup from reverse zone. However, FQDN was intended to check whether client manage to connect to the server he originally intended. This verifies forward DNS lookup. Regards, Vadim On Mon, Jul 21, 2003 at 12:12:49PM -0400, Jue (Jacky) Shu wrote: hi all, maybe it is not a SSL question. I want to make post-connection assertion to prevent man-in-the-middle attack. But I don't know how to get FQDN of the peer side(Not from peer's certificate, it must be other side's real address). Is there any socket fucntion to get peer's FQDN? thank you in advance. Jacky __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: FQDN
In reading his orignal email, I made the assumption that he just wanted to get the hostname + domain of the peer that conencted. To mae the logical choice was to get the peers IP address from the socket data and then do a lookup on that IP Address. Maybe another method will work? On Mon, Jul 21, 2003 at 07:28:51PM +0300, Vadim Fedukovich wrote: On Mon, Jul 21, 2003 at 12:20:05PM -0400, Christopher Fowler wrote: There is no functino in OpenSSL I beleive that does such a thing. What you need to do is get the sockaddr sin_addr data from the accept() function. At that point you have a IP Address. Use gethostbyaddr() to convert that IP into a FQDN. You can then verify that the FQDN of the host matches that in the certificate. I doubt this. Yes, DNS is used for lookup from reverse zone. However, FQDN was intended to check whether client manage to connect to the server he originally intended. This verifies forward DNS lookup. Regards, Vadim On Mon, Jul 21, 2003 at 12:12:49PM -0400, Jue (Jacky) Shu wrote: hi all, maybe it is not a SSL question. I want to make post-connection assertion to prevent man-in-the-middle attack. But I don't know how to get FQDN of the peer side(Not from peer's certificate, it must be other side's real address). Is there any socket fucntion to get peer's FQDN? thank you in advance. Jacky __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: FQDN
Thank you, Chris. Yes, that's what I want to do. But I have to use SSL_accept instead of accept, and peer's ip address is dynamic. Can I get peer's ip address from SSL connection? Thank you again. Jacky Quoting Christopher Fowler [EMAIL PROTECTED]: In reading his orignal email, I made the assumption that he just wanted to get the hostname + domain of the peer that conencted. To mae the logical choice was to get the peers IP address from the socket data and then do a lookup on that IP Address. Maybe another method will work? On Mon, Jul 21, 2003 at 07:28:51PM +0300, Vadim Fedukovich wrote: On Mon, Jul 21, 2003 at 12:20:05PM -0400, Christopher Fowler wrote: There is no functino in OpenSSL I beleive that does such a thing. What you need to do is get the sockaddr sin_addr data from the accept() function. At that point you have a IP Address. Use gethostbyaddr() to convert that IP into a FQDN. You can then verify that the FQDN of the host matches that in the certificate. I doubt this. Yes, DNS is used for lookup from reverse zone. However, FQDN was intended to check whether client manage to connect to the server he originally intended. This verifies forward DNS lookup. Regards, Vadim On Mon, Jul 21, 2003 at 12:12:49PM -0400, Jue (Jacky) Shu wrote: hi all, maybe it is not a SSL question. I want to make post-connection assertion to prevent man-in-the-middle attack. But I don't know how to get FQDN of the peer side(Not from peer's certificate, it must be other side's real address). Is there any socket fucntion to get peer's FQDN? thank you in advance. Jacky __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: FQDN
Jue (Jacky) Shu wrote: Yes, that's what I want to do. But I have to use SSL_accept instead of accept, and peer's ip address is dynamic. Can I get peer's ip address from SSL connection? Normally one makes first an accept and then an SSL_accept. After the accept you can proceed as described by Christopher. Ciao, Richard -- Dr. Richard W. Könning Fujitsu Siemens Computers GmbH, EP LP COM 5 __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: FQDN
On Mon, Jul 21, 2003, Jue (Jacky) Shu wrote: Thank you, Chris. Yes, that's what I want to do. But I have to use SSL_accept instead of accept, and peer's ip address is dynamic. Can I get peer's ip address from SSL connection? You can get the underlying socket fd from the relevant socket BIOs using the appropriate calls, see BIO_s_socket() docs for more info. Which side (client, server) do you want the FQDN for BTW? One thing to be careful of is that DNS spoofing can't be used to fool any checks you make. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.demon.co.uk/ Email: [EMAIL PROTECTED], PGP key: via homepage. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
