Introduction
Today, many Internet services interact with each other via the Internet. A special class of interactions - those in which transfer of confidential information (personal data, secret messages), or teams, implementation of which should be someone clearly confirmed (eg, money transfer or publication of messages from someone's name). Obviously, these services must be protected from intruders.
Unfortunately, not all developers think about the degree of protection for their applications. The problem is compounded somewhat by the fact that many members are developing e-business protocols, which, when implemented in end services, can create serious vulnerabilities if used without proper understanding.
task of this paper - briefly describe the possible types of attacks in the inter-project (ie, server-server) interaction and the means of protection against them - in order to more thoughtful use existing protocols and develop their own. Pre will be considered the foundation of information security, since knowledge is often the final development in this area are somewhat sketchy.
Privacy (or lack of protection) from different types of attacks demonstrates how to protocols today's popular systems : Assist, Cyberplat, WebMoney, ChronoPay, Robokassa and PayPal (payment systems), as well as OpenID, OpenAuth, OAuth (decentralized authentication).
secure communication
So, let's define what we mean by the words "secure communication.
1. Authentication. let server A wants to send a message to the server B. B should be able to verify that the message was sent by A. This test called authentication server A to server B.
2. Data Integrity. We want to make sure that the message transmission has not been changed (for example, was paid $ 50, but confirmation was obtained at 500 $).
3. Privacy interaction. This paragraph implies that the message is received only by those who are entitled to do. As a rule, this paragraph implies encryption data during transmission.
In some cases, you can also consider two items: check access rights and non-repudiation (non-repudiation), but now we'll leave that aside.
cryptographic primitives
Here we must make a digression into the theory. I'm not going to paint the basics of cryptography (aka The article should go beyond reason), but briefly mention the main "cryptographic primitives" to denote the knowledge needed to understand further part of the article. Those interested can follow the link to Wikipedia and learn more.
- There are various systems symmetric encryption. on these systems - a key K, which is known to both parties. This key is used for both encryption and to decrypt the message. Examples of standards: RC2, RC4, RC5, DES, 3-DES, AES, Blowfish, GOST 28147-89, etc.
- There are asymmetric encryption system. Here, each side has a secret key and public key. Outdoor known to all (including the cryptanalyst willing to hack the system), a secret - only one side. Anyone can use the public key of A, to encrypt a message to decrypt the same side of A. This message can ONLY owner of the secret key that is A. Example standard: RSA.
- As a general rule, the public key is distributed in the form of so-called. certificate. Generally speaking, the public key - only part of certificate, but in future I will use these terms as synonymous.
- The same pair, the secret and public key, as a rule, can be used to form digital signature (CPU). In this case, , just as the paper document signature of a person present in the body of the email includes a digital signature generated based on the message and secret key. Signed impossible to generate without using a secret key, but can check it all, using the corresponding public key. So we can verify that a message is sent exactly fit our server, or a man, and was not a "fake." protocols: RSA, DSA, ECDSA, GOST R 34.10-2001.
- There are protocols that enable the two sides to generate a common key K, without passing it through the channel. Examples of protocols - Diffie-Hellman Key Exchange Protocol (hereinafter for short Diffie-Hellman), SRP. First, for example, is used in a popular system today OpenID.
- There are a hash function, assigning the text a set of bits of fixed length. It is believed that the problem of finding two texts have the same hash, "very complicated". Examples: MD5 (which is already "broken»), SHA-1, SHA -256, GOST R 34.11-94.
- There are codes Hash Message Authentication Code (HMAC). This is a function of the message and a key, and giving at the output of the hash string of fixed length. If Both parties have the secret key K, then you can use the HMAC-function as a method for forming a digital signature in a symmetric cryptosystem, as to form and verify the message signature can only 2 sides, with the key.
SSL / TLS and HTTPS
Speaking of "security cooperation", you can set a reasonable (somewhat) the question: all this: authentication, integrity support, encryption, there is a SSL / TLS (HTTPS). Why do I need something else?
Therefore, the second excursion into the theory will be a short reminder What is SSL / TLS and HTTPS.
Minutes SSL (Secure Socket Layer) and its "offspring" TLS (Transport Layer Security) was developed in response to the need for a secure client-server interaction. The protocol operates at the transport layer model OSI. With proper use of it enables us to establish an encrypted connection between client and server. The protocol is being protected from modification and Reading the messages sent in both directions. Also the protocol allows a client (I repeat: if used) to make sure that it has established a connection with exactly the mirror, not the server rogue (in other words, the client can authenticate the server.) There are modifications that allow you to authenticate the client, ie, to provide mutual authentication.
HTTPS (HTTP Secure) - this is the same HTTP, but sent through the channel, a secure protocol SSL / TLS.
It is very important understand that the availability of SSL / TLS-channel partial implementation only means that the connection between your point and the remote server runs on a protocol is well protected in terms of plays and substitution information. But this does not mean anything until you have verified that remote side - it is one with which you wish to contact. Check also this is possible only if the remote certificate is known to you beforehand, and you trust him, or if the same certificate you get over an insecure channel, but signed by "third party" Sc. Certification Centre (Certification Authority or CA). In this case, the public key of CA, used to verify the signatures, again, must be known to you beforehand, to avoid having to send it over an insecure channel. For example, how to ensure that security in browsers ? Certificates main CA (the most famous - COMODO, VeriSign, Go Daddy, Thawte, etc., making a total of several dozen) are embedded in your browser in advance.
And how to implement certificate validation in the code of its service? If you have a certificate in advance, do it fairly easily (eg, PHP-programmers can look towards the curl_setopt (), options and CURLOPT_CAINFO CURLOPT_CAPATH). It is in this way provides secure communication to communicate with the server code, WebMoney. If you are not known beforehand CA-server make such tests in practice is somewhat more complicated, because you will have to select and maintain a collection of certificates of various CA.
In practice, the certificate validation in the code is often not performed, which can lead to one of the two attacks: phishing server or attack "The man in the middle» (Man in the Middle, MITM). This means that between you (A) and the destination server (B ) is one server (M). You are (a) establish an absolutely secure connection with the M, thinking that established a connection with B. Then M establishes a secure connection to B and starts sending him your queries as you - it answers. So way, M can listen to the interaction of A - B, and even modify transmitted messages.
logical question of how the attack spoofing the server and the "middle man" manageable.
Most likely, if both servers are interacting in a serious date Centers (and if the servers themselves, of course, not broke), the implementation of such an attack is very difficult. If the server is located in a corporate, university or home network (designed while not the best way), then, say, ARP-attack is quite allow an attacker to send through a full traffic entering and leaving the network, and then all of these attacks are very simple feasible.
So, why we were not always satisfied with SSL / TLS.
- Clozhnost authenticate any server code applications. As a result - partial use of the protocol, without protection from attack "Man in the middle."
- One-way authentication (yes, there is a modification of the protocol for double-sided, but it is less common, and not all programming languages ??can easily find a ready solution).
- In addition, the architecture of SSL / TLS can not save the message with the sender's digital signature in order to later use it to prove that the message was actually sent by the author (ie, not running protection against repudiation).
Implementing Security in practice
So, let us now return briefly to the "safe interaction" and see how to put into practice we have identified points.
1. authentication usually use a couple of "login - password", or a digital signature generated by one method or another.
2. To check Data Integrity use SSL / TLS and generated an application digital signature.
3. For encryption data, ie, Privacy Most systems use SSL / TLS (there are examples of self-encryption keys, but data encrypt "their" methods is relatively rare).
Speaking of web services, most SSL / TLS is used as HTTPS.
Types of protected applications
Before you finally go to the attacks on the protocols, you must say about the limitations within which the designed system. I would like to mention three basic types of applications that could be considered safe interaction.
1. Two of the interacting parties have the opportunity to advance to exchange for guaranteed a secure channel necessary information: public key, certificates, passwords and so on. This channel can be full-time transfer of necessary information between people (the best), an alternative communication channel (cellular, phone) or even the Internet - if both parties are confident in the absence of a "middle man" or some other method to intercept or modify messages.
2. centralized architecture. Every two sides are unable to agree with each other in advance, but any member of the network trusts a third party, which signs certificates interacting parties and ensure their validity. As an example, may be called PKI (Public Key Infrastructure, PKI) or, with some reservations, the same internet connection, in which a finite number of browsers trust certification Centers (CA), and on this basis can be sure that they interact with the site you want.
3. decentralized architecture. In such applications, there is no single third party. It is important to understand that in such architectures primary goal - to make sure that the second time come to you the same person that came before. That is, for the first time you allow anyone to authenticate (for example, on sites that support OpenID, anyone can authenticate). Suppose further that you have done some contribution to the system: for example, write a message. When you come here next time, the site would give you (and only you) access to edit this message. pritokolov Examples: OpenID, OAuth, protocols Peer-to-Peer.
Attacks and how to protect
And finally, let's consider the basic types of attacks carried out in the Protocols - and how to They are protected.
1. No verification of authorship or authenticity of the message
Let me recall the old joke. In programming, there are two types of errors: the lack of input validation - and all the other errors.
If you were sent M from the A side, you have to make sure that: a) the message really came from A, and b) that it sent a message M, and it has not been altered en route.
An example is illiterate designed protocol is the communication protocol of the payment system Assist with e-shop. After payment of the purchase on the server assists the user back to some address URL_RETURN_OK, which is transmitted in clear text and can be modified by a user-buyer. That is, the user returns after payment of the purchase in our online store, he said: "Thanks, you've just paid for a payment of $ 1000" - but the shop there is absolutely no way to make sure that this is indeed the case. Only later, hands Manager or automated (but not more than 1 time in 10 minutes!) Can verify that the payment is actually passed. The protocol assists, by the way, not modified for more than 4 years. All in all, it is necessary to - add a digital signature.
So how to implement the verification of authorship and integrity of the message.
- Use digital signatures based on a pair of secret and public key. This is probably the most reliable and universal (ie, working in any environment) way. Public key can be transmitted to the receiving side in advance (similar to the method used today, WebMoney, Cyberplat, OAuth, and many others). Public key can be retrieved later by an unsecured connection and verified with a certificate Certification Center (Certification Authority, CA). This method underlies the operation of the PKI (Public Key Infrastructure, PKI), used in large companies.
- Configure the public key to - for example, protocol-based Diffie-Hellman or similar and use it to sign messages (for example, by using HMAC-SHA1). Used in OpenID.
- If it does not matter integrity of the message, but it is only important confirmation of authorship, sometimes uses a pair of "login - the password or secret string to access a protected resource. For example, Flickr photos gives the protocol XML-RPC in response to a request containing a username and password. The system allows you to check out reCAPTCHA CAPTCHA-code entered by the user, authenticating the inspection of the secret string. It should be understood that this method, though simple, is extremely bad that the interception of communications disclose your password to continue an attacker can freely send requests on your behalf. In the case of a digital signature to intercept messages did not allow an attacker.
- Is there an easier (albeit unprotected from attack spoofing the server and the Man in the middle ") way of checking the authenticity of the message. For example, PayPal, in its protocol Instant Payment Notification (IPN) requires the server receiving a confirmation to hold the payment, send a copy of the message back to the server with the question "Are you sending it to me? A similar method is used in the protocol of OpenID (though, when working in a mode other than recommended), just sent back not just the message and the message is digitally signed, and the request has already looks like "Check, if you put this digital signature". A similar scheme operates in OpenAuth. The advantage of the approach can be considered as there is no need to implement cryptographic algorithms with one or two sides.
- Robokassa invented its own original way of forming a digital signature: digital signature is formed as a hash function MD5 of message and secret password. By this method should be treated with caution, if only because that password has to be sufficiently reliable. If the password is short and, especially, if he chooses someone deciphering your password can be a simple task for a hacker.
2. Hope for the reliability of HTTPS.
As stated above, the implementation in HTTPS-protocol authentication arbitrary server that connects to your application - a rather difficult task.
3.
4.
Introduction Today, many Internet services interact with each other via the Internet. A special class of interactions - those in which transfer of confidential information (personal data, secret messages), or teams, implementation of which should be someone clearly confirmed (eg, money transfer or publication of messages from someone's name). Obviously, these services must be protected from intruders. Unfortunately, not all developers think about the degree of protection for their applications. The problem is compounded somewhat by the fact that many members are developing e-business protocols, which, when implemented in end services, can create serious vulnerabilities if used without proper understanding. task of this paper - briefly describe the possible types of attacks in the inter-project (ie, server-server) interaction and the means of protection against them - in order to more thoughtful use existing protocols and develop their own. Pre will be considered the foundation of information security, since knowledge is often the final development in this area are somewhat sketchy.. Privacy (or lack of protection) from different types of attacks demonstrates how to protocols today's popular systems : Assist, Cyberplat, WebMoney, ChronoPay, Robokassa and PayPal (payment systems), as well as OpenID, OpenAuth, OAuth (decentralized authentication).secure communicationSo, let's define what we mean by the words " secure communication .
1.
Authentication
let server A wants to send a message to the server B. B should be able to verify that the message was sent by A. This test called authentication server A to server B.
2.
Data Integrity
We want to make sure that the message transmission has not been changed (for example, was paid $ 50, but confirmation was obtained at 500 $).
3.
Privacy interaction
This paragraph implies that the message is received only by those who are entitled to do. As a rule, this paragraph implies
encryption
data during transmission.
In some cases, you can also consider two items: check access rights and non-repudiation (non-repudiation), but now we'll leave that aside.
cryptographic primitives
Here we must make a digression into the theory. I'm not going to paint the basics of cryptography (aka The article should go beyond reason), but briefly mention the main "
- cryptographic primitives
- " to denote the knowledge needed to understand further part of the article. Those interested can follow the link to Wikipedia and learn more.
- There are various systems
symmetric encryption on these systems - a key K, which is known to both parties. This key is used for both encryption and to decrypt the message. Examples of standards: RC2, RC4, RC5, DES, 3-DES, AES, Blowfish, GOST 28147-89, etc.
There are asymmetric encryption system
Here, each side has a secret key and public key. Outdoor known to all (including the cryptanalyst willing to hack the system), a secret - only one side. Anyone can use the public key of A, to encrypt a message to decrypt the same side of A. This message can ONLY owner of the secret key that is A. Example standard: RSA.
As a general rule, the public key is distributed in the form of so-called.
certificate
- Generally speaking, the public key - only part of certificate, but in future I will use these terms as synonymous.
- The same pair, the secret and public key, as a rule, can be used to form
digital signature <<>> (CPU). In this case, , just as the paper document signature of a person present in the body of the email includes a digital signature generated based on the message and secret key. Signed impossible to generate without using a secret key, but can check it all, using the corresponding public key. So we can verify that a message is sent exactly fit our server, or a man, and was not a "fake." protocols: RSA, DSA, ECDSA, GOST R 34.10-2001. <<>> There are protocols that enable the two sides <> > to generate a common key K, without passing it through the channel <<>> Examples of protocols - Diffie-Hellman Key Exchange Protocol (hereinafter for short Diffie-Hellman), SRP. First, for example, is used in a popular system today OpenID. << >> There are a hash function, assigning the text a set of bits of fixed length. It is believed that the problem of finding two texts have the same hash, "very complicated". Examples: MD5 (which is already "broken»), SHA-1, SHA -256, GOST R 34.11-94. <<>> There are codes <<>> Hash Message Authentication Code <<>> (HMAC). This is a function of the message and a key, and giving at the output of the hash string of fixed length. If Both parties have the secret key K, then you can use the HMAC-function as a method for forming a digital signature in a symmetric cryptosystem, as to form and verify the message signature can only 2 sides, with the key. <<>> SSL / TLS and HTTPS <<>> Speaking of "security cooperation", you can set a reasonable (somewhat) the question: all this: authentication, integrity support, encryption, there is a SSL / TLS (HTTPS). <<>> Why do I need something else? < >> Therefore, the second excursion into the theory will be a short reminder <<>> What is SSL / TLS and HTTPS <<>> Minutes <<>> SSL <<>> (Secure Socket Layer) and its "offspring" <> > TLS <<>> (Transport Layer Security) was developed in response to the need for a secure client-server interaction. The protocol operates at the transport layer model OSI. With proper use of it enables us to establish an encrypted connection between client and server. The protocol is being protected from modification and Reading the messages sent in both directions. Also the protocol allows a client (I repeat: if used) to make sure that it has established a connection with exactly the mirror, not the server rogue (in other words, the client can authenticate the server.) There are modifications that allow you to authenticate the client, ie, to provide mutual authentication. <<>> HTTPS <<>> (HTTP Secure) - this is the same HTTP, but sent through the channel, a secure protocol SSL / TLS. <<>> It is very important understand that the availability of SSL / TLS-channel partial implementation only means that the connection between your point and the remote server runs on a protocol is well protected in terms of plays and substitution information. But this does not mean anything until you have verified that remote side - it is one with which you wish to contact. Check also this is possible only if the remote certificate is known to you beforehand, and you trust him, or if the same certificate you get over an insecure channel, but signed by "third party" Sc. Certification Centre (Certification Authority or CA). In this case, the public key of CA, used to verify the signatures, again, must be known to you beforehand, to avoid having to send it over an insecure channel. For example, how to ensure that security in browsers ? Certificates main CA (the most famous - COMODO, VeriSign, Go Daddy, Thawte, etc., making a total of several dozen) are embedded in your browser in advance. <<>> And how to implement certificate validation in the code of its service? If you have a certificate in advance, do it fairly easily (eg, PHP-programmers can look towards the curl_setopt (), options and CURLOPT_CAINFO CURLOPT_CAPATH). It is in this way provides secure communication to communicate with the server code, WebMoney. If you are not known beforehand CA-server make such tests in practice is somewhat more complicated, because you will have to select and maintain a collection of certificates of various CA. <<>> In practice, the certificate validation in the code is often not performed, which can lead to one of the <<>> two attacks < >>: <>> phishing server <<>> or attack "<<>> The man in the middle <<>>» (Man in the Middle, MITM). This means that between you (A) and the destination server (B ) is one server (M). You are (a) establish an absolutely secure connection with the M, thinking that established a connection with B. Then M establishes a secure connection to B and starts sending him your queries as you - it answers. So way, M can listen to the interaction of A - B, and even modify transmitted messages. <<>> logical question of how the attack spoofing the server and the "middle man" manageable. <<>> Most likely, if both servers are interacting in a serious date Centers (and if the servers themselves, of course, not broke), the implementation of such an attack is very difficult. If the server is located in a corporate, university or home network (designed while not the best way), then, say, ARP-attack is quite allow an attacker to send through a full traffic entering and leaving the network, and then all of these attacks are very simple feasible. <<>> So, why we were not always satisfied with SSL / TLS. <<>> Clozhnost authenticate any server code applications. As a result - partial use of the protocol, without protection from attack "Man in the middle." <<>> One-way authentication (yes, there is a modification of the protocol for double-sided, but it is less common, and not all programming languages ??can easily find a ready solution). <<>> In addition, the architecture of SSL / TLS can not save the message with the sender's digital signature in order to later use it to prove that the message was actually sent by the author (ie, not running protection against repudiation). <<>> Implementing Security in practice <<>> So, let us now return briefly to the "<<>> safe interaction <>" and see how to put into practice we have identified points. <<>> 1. < <>> authentication <>> usually use a couple of "login - password", or a digital signature generated by one method or another. <<>> 2. To check <<>> Data Integrity <<>> use SSL / TLS and generated an application digital signature. <<>> 3. For <<>> encryption <<>> data, ie, <> Privacy <>> Most systems use SSL / TLS (there are examples of self-encryption keys, but data encrypt "their" methods is relatively rare). <<>> Speaking of web services, most SSL / TLS is used as HTTPS. <<>> Types of protected applications <<>> Before you finally go to the attacks on the protocols, you must say about the limitations within which the designed system. I would like to mention three basic types of applications that could be considered safe interaction. <<>> 1. <<>> Two of the interacting parties have the opportunity to advance to exchange for guaranteed a secure channel necessary information <<>>: public key, certificates, passwords and so on. This channel can be full-time transfer of necessary information between people (the best), an alternative communication channel (cellular, phone) or even the Internet - if both parties are confident in the absence of a "middle man" or some other method to intercept or modify messages. <<>> 2. <<>> centralized architecture <<>> Every two sides are unable to agree with each other in advance, but any member of the network trusts a < >> third party <<>> which signs certificates interacting parties and ensure their validity. As an example, may be called PKI (Public Key Infrastructure, PKI) or, with some reservations, the same internet connection, in which a finite number of browsers trust certification Centers (CA), and on this basis can be sure that they interact with the site you want. <<>> 3. <<>> decentralized architecture <<>> In such applications, there is no single third party. It is important to understand that in such architectures primary goal - to make sure that the <<>> second time <<>> come to you the same person that came before. That is, for the first time you allow anyone to authenticate (for example, on sites that support OpenID, anyone can authenticate). Suppose further that you have done some <<>> contribution to the system <<>>: for example, write a message. When you come here next time, the site would give you (and only you) access to edit this message. pritokolov Examples: OpenID, OAuth, protocols Peer-to-Peer. <<>> Attacks and how to protect <<>> And finally, let's consider the basic types of attacks carried out in the Protocols - and how to They are protected. <<>> 1. No verification of authorship or authenticity of the message <<>> Let me recall the old joke. In programming, there are two types of errors: the lack of input validation - and all the other errors. <<>> If you were sent M from the A side, you have to make sure that: a) the message really came from A, and b) that it sent a message M, and it has not been altered en route. <<>> An example is illiterate designed protocol is the communication protocol of the payment system Assist with e-shop. After payment of the purchase on the server assists the user back to some address URL_RETURN_OK, which is transmitted in clear text and can be modified by the user-buyer. That is, the user returns after payment of the purchase in our online store, he said: "Thanks, you've just paid for a payment of $ 1000" - but the shop there is absolutely no way to make sure that this is indeed the case. Only later, hands Manager or automated (but not more than 1 time in 10 minutes!) Can verify that the payment is actually passed. The protocol assists, by the way, not modified for more than 4 years. All in all, it is necessary to - add a digital signature. <<>> So how to implement the verification of authorship and integrity of the message. <<>> Use digital signatures based on a pair of secret and public key. This is probably the most reliable and universal (ie, working in any environment) way. Public key can be transmitted to the receiving side in advance (similar to the method used today, WebMoney, Cyberplat, OAuth, and many others). Public key can be retrieved later by an unsecured connection and verified with a certificate Certification Center (Certification Authority, CA). This method underlies the operation of the PKI (Public Key Infrastructure, PKI), used in large companies. <<>> Configure the public key to - for example, protocol-based Diffie-Hellman or similar and use it to sign messages (for example, by using HMAC-SHA1). Used in OpenID. <<>> If it does not matter integrity of the message, but it is only important confirmation of authorship, sometimes uses a pair of "login - the password or secret string to access a protected resource. For example, Flickr photos gives the protocol XML-RPC in response to a request containing a username and password. The system allows you to check out reCAPTCHA CAPTCHA-code entered by the user, authenticating the inspection of the secret string. It should be understood that this method, though simple, is extremely bad that the interception of communications disclose your password to continue an attacker can freely send requests on your behalf. In the case of a digital signature to intercept messages did not allow an attacker. <<>> Is there an easier (albeit unprotected from attack spoofing the server and the Man in the middle ") way of checking the authenticity of the message. For example, PayPal, in its protocol Instant Payment Notification (IPN) requires the server receiving a confirmation to hold the payment, send a copy of the message back to the server with the question "<<>> Are you sending it to me <<>>? A similar method is used in the protocol of OpenID (though, when working in a mode other than recommended), just sent back not just the message and the message is digitally signed, and the request has already looks like "<<>> Check, if you put this digital signature <> > ". A similar scheme operates in OpenAuth. The advantage of the approach can be considered as there is no need to implement cryptographic algorithms with one or two sides. <<>> Robokassa invented its own original way of forming a digital signature: digital signature is formed as a hash function MD5 of message and secret password. By this method should be treated with caution, if only because that password has to be sufficiently reliable. If the password is short and, especially, if he chooses someone deciphering your password can be a simple task for a hacker. <<>> 2. Hope for the reliability of HTTPS. <<>> As stated above, the implementation in HTTPS-protocol authentication arbitrary server that connects to your application - a rather difficult task. We have considered above details, a brief derivation of which is simple: no authentication server certificate meaning HTTPS can be reduced to zero. <<>> None of the protocols, decentralized authentication - whether OpenID, OpenAuth, OAuth, is not protected from attack spoofing the server, or "middle man". In some cases, payment systems (PayPal, Assist) can be attacked in this way. As a result, you can convince an application online store that has occurred payment, when in fact it was not. <<>> I stress once again that, from this attack can be defended if establishing HTTPS-connection server has a sufficient number of certificates of major CA Internet (VeriSign, COMODO, etc.), but in practice it is sometimes difficult to realizable. <<>> And, I stress that for <<>> decentralized systems <<>> it <<>> fundamentally insoluble problem <<>> While commercial payment systems related to our classification (see above) to systems, part of which may be "<<>> to agree in advance <<>>" This attack <<>> warned <<>> competent in designing the protocol. An example of such implementation shows WebMoney, provides a certificate to authenticate the HTTPS-connection. (It seems, Chronopay so too does - correct me). <<>> 3. Attack of the Man in the middle »(Man in the Middle, MITM). <<>> We reviewed the MITM attack to the protocol HTTPS. However, other protocols may also be vulnerable to this type of attack. <<>> An example of this - Diffie-Hellman, used in OpenID. As mentioned above, the gist of the generation of a common key to the two parties: A and B. But if we have someone "in the middle (M), who can change the traffic, it may be that a generated key shared with M K1, and B - in common with the M key K2. In the end, "Man in the middle" M can sign and read any data coming from any direction. <<>> Of course, this attack does not take place in OpenID, if the client and server (OpenID Provider and Relying Party) communicate via HTTPS with a full test certificate. <<>> 4. Transmission of the secret key to an open channel. <<>> Many developers do not understand the secret key. The entire security infrastructure using public key based on the fact that the interacting parties someone can unconditionally trust. Second server, third party - does not matter. As a rule, the question of 'trust' rests on the verification of digital signatures using public key of the subscriber message. All security could collapse if the public key (certificate) is sent over an insecure channel and can be modified on the path.
|