Can you prevent a man in the middle from reading the message?
$begingroup$
I have heard about all these Man-In-The-Middle Attack preventions and I am wondering, how this can possibly work if the man in the middle only listens to your stream and does not want to change the message itself.
Can the man in the middle not just take the keys swapped by the opponents, change the keys and then decrypt and encrypt the message again?
How can a certificate prevent this?
Edit:
I have heard that the certificate authority generally says: "Yeah, that is the other ones key". But how can I be certain, that the signature of the certificate is not fudged?
cryptography security
edited Feb 24 at 9:00
Discrete lizard♦
4,22411536
asked Feb 23 at 11:06
TVSuchtyTVSuchty
463
$endgroup$
add a comment |
$begingroup$
I have heard about all these Man-In-The-Middle Attack preventions and I am wondering, how this can possibly work if the man in the middle only listens to your stream and does not want to change the message itself.
Can the man in the middle not just take the keys swapped by the opponents, change the keys and then decrypt and encrypt the message again?
How can a certificate prevent this?
Edit:
I have heard that the certificate authority generally says: "Yeah, that is the other ones key". But how can I be certain, that the signature of the certificate is not fudged?
cryptography security
edited Feb 24 at 9:00
Discrete lizard♦
4,22411536
asked Feb 23 at 11:06
TVSuchtyTVSuchty
463
$endgroup$
add a comment |
$begingroup$
I have heard about all these Man-In-The-Middle Attack preventions and I am wondering, how this can possibly work if the man in the middle only listens to your stream and does not want to change the message itself.
Can the man in the middle not just take the keys swapped by the opponents, change the keys and then decrypt and encrypt the message again?
How can a certificate prevent this?
Edit:
I have heard that the certificate authority generally says: "Yeah, that is the other ones key". But how can I be certain, that the signature of the certificate is not fudged?
cryptography security
edited Feb 24 at 9:00
Discrete lizard♦
4,22411536
asked Feb 23 at 11:06
TVSuchtyTVSuchty
463
$endgroup$
I have heard about all these Man-In-The-Middle Attack preventions and I am wondering, how this can possibly work if the man in the middle only listens to your stream and does not want to change the message itself.
Can the man in the middle not just take the keys swapped by the opponents, change the keys and then decrypt and encrypt the message again?
How can a certificate prevent this?
Edit:
I have heard that the certificate authority generally says: "Yeah, that is the other ones key". But how can I be certain, that the signature of the certificate is not fudged?
cryptography security
cryptography security
edited Feb 24 at 9:00
Discrete lizard♦
4,22411536
asked Feb 23 at 11:06
TVSuchtyTVSuchty
463
edited Feb 24 at 9:00
Discrete lizard♦
4,22411536
asked Feb 23 at 11:06
TVSuchtyTVSuchty
463
edited Feb 24 at 9:00
Discrete lizard♦
4,22411536
edited Feb 24 at 9:00
Discrete lizard♦
4,22411536
edited Feb 24 at 9:00
Discrete lizard♦
4,22411536
4,22411536
asked Feb 23 at 11:06
TVSuchtyTVSuchty
463
asked Feb 23 at 11:06
TVSuchtyTVSuchty
463
asked Feb 23 at 11:06
TVSuchtyTVSuchty
463
463
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
$begingroup$
Can the man in the middle not just take the keys swapped by the opponents, change the keys and then decrypt and encrypt the message again?
Yes, they can.
A key exchange protocol like (the "textbook" version of) DH is secure against eavesdropping (i.e., simply observing what is being transmitted on the channel), but completely breaks down against man-in-the-middle (MITM) attacks, as you have stated.
Certificates are an attempt remedy this, but another problem arises: How can you ensure both parties receive the correct certificate? Obviously you cannot just send the certificates over the insecure channel since this is again susceptible to a MITM attack.
The solution is the existence of an alternative, (completely) secure channel. This would be either the two parties meeting in person and exchanging their certificates physically or over some alternative, trusted channel (e.g., over telephone, if it can be trusted).
In computer networks, the alternative channel is usually a public-key infrastructure (PKI). This means your operating system or browser has a set of preconfigured root certificates from which other certificates are signed (and possibly even further certificates using these as intermediate certificates). Hence, when you visit some website, it presents a signed certificate, which is signed using (a chain of) certificates which you already trust. Then, by using this certificate, an authenticated key exchange is possible (e.g., to agree on an ephemeral key to use with ordinary symmetric encryption).
answered Feb 23 at 11:39
dkaeaedkaeae
1,869721
$endgroup$
$begingroup$
So we are basically communicating the certificates through a second channel, we know to be secure?
$endgroup$
– TVSuchty
Feb 23 at 11:44
$begingroup$
Yes; otherwise, a MITM attack is always possible. It is a bit counter-intuitive to think of a structure as a PKI as a "channel", but the idea is not so far-fetched if you consider it simply as a way of transmitting information (in this case, certificates).
$endgroup$
– dkaeae
Feb 23 at 11:45
$begingroup$
But why would not we talk about the channel, we know to be secure, in the first place?
$endgroup$
– TVSuchty
Feb 23 at 11:47
1
$begingroup$
@TVSuchty You need some initial trusted key, but that only has to be communicated once in a lifetime. That key could also be the key of a certification authority, which you trust to issue certificates for others. E.g. when you install a browser, that comes with the keys of many CAs. When you go to an https site, you receive a key for the site and a certificate emitted by a CA stating that the key is correct, so you can start https just fine. But this assumes 1) the CA keys in the browser are the right ones, and 2) the CAs themselves can be trusted.
$endgroup$
– chi
Feb 23 at 11:51
1
$begingroup$
@TVSuchty One trusted key is enough, as long as it's the public key for a CA you can trust. Firefox uses ~100 CA keys.
$endgroup$
– chi
Feb 23 at 12:33
|
show 4 more comments
$begingroup$
In a man-in-the-middle attack, you ask Bob for his key but Eve intercepts the message and sends you her key instead. She asks Bob for his key and then passes messages between you and Bob, decrypting them, reading and/or changing them in the process.
The problem is that you don't know whether or not you really have Bob's key. Certificates get around this because the certification authority (CA) gives Bob a digitally signed message saying "Bob's key is 12345". You can verify this certificate because there aren't many CAs so your browser just contains a list of valid CA keys. Now, if Eve intercepts your attempt to start encrypted communication with Bob, she has two choices. If she tells you that Bob's key is 67890, then either she doesn't provide a certificate and you say "Sorry, you need to prove that" or she provides a fake certificate and you say "That certificate isn't valid." Alternatively, she tells you that Bob's key is 12345 and provides a valid certificate of that, but this is no use to her because she doesn't know Bob's private key, so she can't decrypt the messages she's relaying between the two of you.
answered Feb 23 at 11:31
David RicherbyDavid Richerby
67.7k15102193
$endgroup$
$begingroup$
Why Eve cannot just send me Bobs certificate? I mean what is special with Bob's key so that eve cannot replicate a similar one? How do I know that this key is a certified one? How do I verify the certificate?
$endgroup$
– TVSuchty
Feb 23 at 11:35
$begingroup$
I told you why she can't send you Bob's certificate (or, rather, why sending you Bob's certificate doesn't help her). There's no such thing as "a similar key". You know the key is certified because you have the certificate. You check the certificate by verifying the digital signature using the CA's key.
$endgroup$
– David Richerby
Feb 23 at 11:39
$begingroup$
@TVSuchty Eve must first decrypt the message to read it and then re-encrypt the message to pass it to on. Only Bob's private signing certificate will allow you to encrypt like Bob but the unfortunate person subject to the MITM attack must be able to prove if they have Bob's certificate in order to know if Eve's has been supplied instead. This is the reason some secure applications prompt you to accept the encryption key the first time and each time it changes.
$endgroup$
– Willtech
Feb 24 at 0:33
1
$begingroup$
@TVSuchty A certificate basically says "I am X, and you can trust that I am X because Y says so". Eve can easily create a certificate that says "I am Bob, and you can trust that I'm Bob because Eve says so". If my computer gets that certificate it just laughs. "Eve says so" is no reason to believe it's Bob's certificate. "Because Verisign says so", with Verisign being one of say 100 certificate providers that were installed on your computer by the manufacturer, that's a reason to believe it. But Eve can't forge such a certificate.
$endgroup$
– gnasher729
Feb 24 at 14:51
$begingroup$
Another answer to “why can’t eve send me bob’s certificate: “ Eve can either try to forge Bob’s certificate, or steal it. Maybe a million dollars is enough to bribe one of Bob’s employees to hand over a copy of Bob’s certificate. Bob has to make sure it’s hard to steal the certificate. If stolen, a certificate can be revoked and won’t be accepted anymore. The certificate will now say “this is a genuine certificate of Bob’s, but it was reported stolen, so don’t trust it”.
$endgroup$
– gnasher729
Feb 24 at 20:06
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
return StackExchange.using("mathjaxEditing", function () {
StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix) {
StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["$", "$"], ["\\(","\\)"]]);
});
});
}, "mathjax-editing");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "419"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcs.stackexchange.com%2fquestions%2f104745%2fcan-you-prevent-a-man-in-the-middle-from-reading-the-message%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
$begingroup$
Can the man in the middle not just take the keys swapped by the opponents, change the keys and then decrypt and encrypt the message again?
Yes, they can.
A key exchange protocol like (the "textbook" version of) DH is secure against eavesdropping (i.e., simply observing what is being transmitted on the channel), but completely breaks down against man-in-the-middle (MITM) attacks, as you have stated.
Certificates are an attempt remedy this, but another problem arises: How can you ensure both parties receive the correct certificate? Obviously you cannot just send the certificates over the insecure channel since this is again susceptible to a MITM attack.
The solution is the existence of an alternative, (completely) secure channel. This would be either the two parties meeting in person and exchanging their certificates physically or over some alternative, trusted channel (e.g., over telephone, if it can be trusted).
In computer networks, the alternative channel is usually a public-key infrastructure (PKI). This means your operating system or browser has a set of preconfigured root certificates from which other certificates are signed (and possibly even further certificates using these as intermediate certificates). Hence, when you visit some website, it presents a signed certificate, which is signed using (a chain of) certificates which you already trust. Then, by using this certificate, an authenticated key exchange is possible (e.g., to agree on an ephemeral key to use with ordinary symmetric encryption).
answered Feb 23 at 11:39
dkaeaedkaeae
1,869721
$endgroup$
$begingroup$
So we are basically communicating the certificates through a second channel, we know to be secure?
$endgroup$
– TVSuchty
Feb 23 at 11:44
$begingroup$
Yes; otherwise, a MITM attack is always possible. It is a bit counter-intuitive to think of a structure as a PKI as a "channel", but the idea is not so far-fetched if you consider it simply as a way of transmitting information (in this case, certificates).
$endgroup$
– dkaeae
Feb 23 at 11:45
$begingroup$
But why would not we talk about the channel, we know to be secure, in the first place?
$endgroup$
– TVSuchty
Feb 23 at 11:47
1
$begingroup$
@TVSuchty You need some initial trusted key, but that only has to be communicated once in a lifetime. That key could also be the key of a certification authority, which you trust to issue certificates for others. E.g. when you install a browser, that comes with the keys of many CAs. When you go to an https site, you receive a key for the site and a certificate emitted by a CA stating that the key is correct, so you can start https just fine. But this assumes 1) the CA keys in the browser are the right ones, and 2) the CAs themselves can be trusted.
$endgroup$
– chi
Feb 23 at 11:51
1
$begingroup$
@TVSuchty One trusted key is enough, as long as it's the public key for a CA you can trust. Firefox uses ~100 CA keys.
$endgroup$
– chi
Feb 23 at 12:33
|
show 4 more comments
$begingroup$
Can the man in the middle not just take the keys swapped by the opponents, change the keys and then decrypt and encrypt the message again?
Yes, they can.
A key exchange protocol like (the "textbook" version of) DH is secure against eavesdropping (i.e., simply observing what is being transmitted on the channel), but completely breaks down against man-in-the-middle (MITM) attacks, as you have stated.
Certificates are an attempt remedy this, but another problem arises: How can you ensure both parties receive the correct certificate? Obviously you cannot just send the certificates over the insecure channel since this is again susceptible to a MITM attack.
The solution is the existence of an alternative, (completely) secure channel. This would be either the two parties meeting in person and exchanging their certificates physically or over some alternative, trusted channel (e.g., over telephone, if it can be trusted).
In computer networks, the alternative channel is usually a public-key infrastructure (PKI). This means your operating system or browser has a set of preconfigured root certificates from which other certificates are signed (and possibly even further certificates using these as intermediate certificates). Hence, when you visit some website, it presents a signed certificate, which is signed using (a chain of) certificates which you already trust. Then, by using this certificate, an authenticated key exchange is possible (e.g., to agree on an ephemeral key to use with ordinary symmetric encryption).
answered Feb 23 at 11:39
dkaeaedkaeae
1,869721
$endgroup$
$begingroup$
So we are basically communicating the certificates through a second channel, we know to be secure?
$endgroup$
– TVSuchty
Feb 23 at 11:44
$begingroup$
Yes; otherwise, a MITM attack is always possible. It is a bit counter-intuitive to think of a structure as a PKI as a "channel", but the idea is not so far-fetched if you consider it simply as a way of transmitting information (in this case, certificates).
$endgroup$
– dkaeae
Feb 23 at 11:45
$begingroup$
But why would not we talk about the channel, we know to be secure, in the first place?
$endgroup$
– TVSuchty
Feb 23 at 11:47
1
$begingroup$
@TVSuchty You need some initial trusted key, but that only has to be communicated once in a lifetime. That key could also be the key of a certification authority, which you trust to issue certificates for others. E.g. when you install a browser, that comes with the keys of many CAs. When you go to an https site, you receive a key for the site and a certificate emitted by a CA stating that the key is correct, so you can start https just fine. But this assumes 1) the CA keys in the browser are the right ones, and 2) the CAs themselves can be trusted.
$endgroup$
– chi
Feb 23 at 11:51
1
$begingroup$
@TVSuchty One trusted key is enough, as long as it's the public key for a CA you can trust. Firefox uses ~100 CA keys.
$endgroup$
– chi
Feb 23 at 12:33
|
show 4 more comments
$begingroup$
Can the man in the middle not just take the keys swapped by the opponents, change the keys and then decrypt and encrypt the message again?
Yes, they can.
A key exchange protocol like (the "textbook" version of) DH is secure against eavesdropping (i.e., simply observing what is being transmitted on the channel), but completely breaks down against man-in-the-middle (MITM) attacks, as you have stated.
Certificates are an attempt remedy this, but another problem arises: How can you ensure both parties receive the correct certificate? Obviously you cannot just send the certificates over the insecure channel since this is again susceptible to a MITM attack.
The solution is the existence of an alternative, (completely) secure channel. This would be either the two parties meeting in person and exchanging their certificates physically or over some alternative, trusted channel (e.g., over telephone, if it can be trusted).
In computer networks, the alternative channel is usually a public-key infrastructure (PKI). This means your operating system or browser has a set of preconfigured root certificates from which other certificates are signed (and possibly even further certificates using these as intermediate certificates). Hence, when you visit some website, it presents a signed certificate, which is signed using (a chain of) certificates which you already trust. Then, by using this certificate, an authenticated key exchange is possible (e.g., to agree on an ephemeral key to use with ordinary symmetric encryption).
answered Feb 23 at 11:39
dkaeaedkaeae
1,869721
$endgroup$
Can the man in the middle not just take the keys swapped by the opponents, change the keys and then decrypt and encrypt the message again?
Yes, they can.
A key exchange protocol like (the "textbook" version of) DH is secure against eavesdropping (i.e., simply observing what is being transmitted on the channel), but completely breaks down against man-in-the-middle (MITM) attacks, as you have stated.
Certificates are an attempt remedy this, but another problem arises: How can you ensure both parties receive the correct certificate? Obviously you cannot just send the certificates over the insecure channel since this is again susceptible to a MITM attack.
The solution is the existence of an alternative, (completely) secure channel. This would be either the two parties meeting in person and exchanging their certificates physically or over some alternative, trusted channel (e.g., over telephone, if it can be trusted).
In computer networks, the alternative channel is usually a public-key infrastructure (PKI). This means your operating system or browser has a set of preconfigured root certificates from which other certificates are signed (and possibly even further certificates using these as intermediate certificates). Hence, when you visit some website, it presents a signed certificate, which is signed using (a chain of) certificates which you already trust. Then, by using this certificate, an authenticated key exchange is possible (e.g., to agree on an ephemeral key to use with ordinary symmetric encryption).
answered Feb 23 at 11:39
dkaeaedkaeae
1,869721
edited Feb 23 at 11:46
answered Feb 23 at 11:39
dkaeaedkaeae
1,869721
answered Feb 23 at 11:39
dkaeaedkaeae
1,869721
answered Feb 23 at 11:39
dkaeaedkaeae
1,869721
1,869721
$begingroup$
So we are basically communicating the certificates through a second channel, we know to be secure?
$endgroup$
– TVSuchty
Feb 23 at 11:44
$begingroup$
Yes; otherwise, a MITM attack is always possible. It is a bit counter-intuitive to think of a structure as a PKI as a "channel", but the idea is not so far-fetched if you consider it simply as a way of transmitting information (in this case, certificates).
$endgroup$
– dkaeae
Feb 23 at 11:45
$begingroup$
But why would not we talk about the channel, we know to be secure, in the first place?
$endgroup$
– TVSuchty
Feb 23 at 11:47
1
$begingroup$
@TVSuchty You need some initial trusted key, but that only has to be communicated once in a lifetime. That key could also be the key of a certification authority, which you trust to issue certificates for others. E.g. when you install a browser, that comes with the keys of many CAs. When you go to an https site, you receive a key for the site and a certificate emitted by a CA stating that the key is correct, so you can start https just fine. But this assumes 1) the CA keys in the browser are the right ones, and 2) the CAs themselves can be trusted.
$endgroup$
– chi
Feb 23 at 11:51
1
$begingroup$
@TVSuchty One trusted key is enough, as long as it's the public key for a CA you can trust. Firefox uses ~100 CA keys.
$endgroup$
– chi
Feb 23 at 12:33
|
show 4 more comments
$begingroup$
So we are basically communicating the certificates through a second channel, we know to be secure?
$endgroup$
– TVSuchty
Feb 23 at 11:44
$begingroup$
Yes; otherwise, a MITM attack is always possible. It is a bit counter-intuitive to think of a structure as a PKI as a "channel", but the idea is not so far-fetched if you consider it simply as a way of transmitting information (in this case, certificates).
$endgroup$
– dkaeae
Feb 23 at 11:45
$begingroup$
But why would not we talk about the channel, we know to be secure, in the first place?
$endgroup$
– TVSuchty
Feb 23 at 11:47
1
$begingroup$
@TVSuchty You need some initial trusted key, but that only has to be communicated once in a lifetime. That key could also be the key of a certification authority, which you trust to issue certificates for others. E.g. when you install a browser, that comes with the keys of many CAs. When you go to an https site, you receive a key for the site and a certificate emitted by a CA stating that the key is correct, so you can start https just fine. But this assumes 1) the CA keys in the browser are the right ones, and 2) the CAs themselves can be trusted.
$endgroup$
– chi
Feb 23 at 11:51
1
$begingroup$
@TVSuchty One trusted key is enough, as long as it's the public key for a CA you can trust. Firefox uses ~100 CA keys.
$endgroup$
– chi
Feb 23 at 12:33
$begingroup$
So we are basically communicating the certificates through a second channel, we know to be secure?
$endgroup$
– TVSuchty
Feb 23 at 11:44
$begingroup$
So we are basically communicating the certificates through a second channel, we know to be secure?
$endgroup$
– TVSuchty
Feb 23 at 11:44
$begingroup$
Yes; otherwise, a MITM attack is always possible. It is a bit counter-intuitive to think of a structure as a PKI as a "channel", but the idea is not so far-fetched if you consider it simply as a way of transmitting information (in this case, certificates).
$endgroup$
– dkaeae
Feb 23 at 11:45
$begingroup$
Yes; otherwise, a MITM attack is always possible. It is a bit counter-intuitive to think of a structure as a PKI as a "channel", but the idea is not so far-fetched if you consider it simply as a way of transmitting information (in this case, certificates).
$endgroup$
– dkaeae
Feb 23 at 11:45
$begingroup$
But why would not we talk about the channel, we know to be secure, in the first place?
$endgroup$
– TVSuchty
Feb 23 at 11:47
$begingroup$
But why would not we talk about the channel, we know to be secure, in the first place?
$endgroup$
– TVSuchty
Feb 23 at 11:47
1
1
$begingroup$
@TVSuchty You need some initial trusted key, but that only has to be communicated once in a lifetime. That key could also be the key of a certification authority, which you trust to issue certificates for others. E.g. when you install a browser, that comes with the keys of many CAs. When you go to an https site, you receive a key for the site and a certificate emitted by a CA stating that the key is correct, so you can start https just fine. But this assumes 1) the CA keys in the browser are the right ones, and 2) the CAs themselves can be trusted.
$endgroup$
– chi
Feb 23 at 11:51
$begingroup$
@TVSuchty You need some initial trusted key, but that only has to be communicated once in a lifetime. That key could also be the key of a certification authority, which you trust to issue certificates for others. E.g. when you install a browser, that comes with the keys of many CAs. When you go to an https site, you receive a key for the site and a certificate emitted by a CA stating that the key is correct, so you can start https just fine. But this assumes 1) the CA keys in the browser are the right ones, and 2) the CAs themselves can be trusted.
$endgroup$
– chi
Feb 23 at 11:51
1
1
$begingroup$
@TVSuchty One trusted key is enough, as long as it's the public key for a CA you can trust. Firefox uses ~100 CA keys.
$endgroup$
– chi
Feb 23 at 12:33
$begingroup$
@TVSuchty One trusted key is enough, as long as it's the public key for a CA you can trust. Firefox uses ~100 CA keys.
$endgroup$
– chi
Feb 23 at 12:33
|
show 4 more comments
$begingroup$
In a man-in-the-middle attack, you ask Bob for his key but Eve intercepts the message and sends you her key instead. She asks Bob for his key and then passes messages between you and Bob, decrypting them, reading and/or changing them in the process.
The problem is that you don't know whether or not you really have Bob's key. Certificates get around this because the certification authority (CA) gives Bob a digitally signed message saying "Bob's key is 12345". You can verify this certificate because there aren't many CAs so your browser just contains a list of valid CA keys. Now, if Eve intercepts your attempt to start encrypted communication with Bob, she has two choices. If she tells you that Bob's key is 67890, then either she doesn't provide a certificate and you say "Sorry, you need to prove that" or she provides a fake certificate and you say "That certificate isn't valid." Alternatively, she tells you that Bob's key is 12345 and provides a valid certificate of that, but this is no use to her because she doesn't know Bob's private key, so she can't decrypt the messages she's relaying between the two of you.
answered Feb 23 at 11:31
David RicherbyDavid Richerby
67.7k15102193
$endgroup$
$begingroup$
Why Eve cannot just send me Bobs certificate? I mean what is special with Bob's key so that eve cannot replicate a similar one? How do I know that this key is a certified one? How do I verify the certificate?
$endgroup$
– TVSuchty
Feb 23 at 11:35
$begingroup$
I told you why she can't send you Bob's certificate (or, rather, why sending you Bob's certificate doesn't help her). There's no such thing as "a similar key". You know the key is certified because you have the certificate. You check the certificate by verifying the digital signature using the CA's key.
$endgroup$
– David Richerby
Feb 23 at 11:39
$begingroup$
@TVSuchty Eve must first decrypt the message to read it and then re-encrypt the message to pass it to on. Only Bob's private signing certificate will allow you to encrypt like Bob but the unfortunate person subject to the MITM attack must be able to prove if they have Bob's certificate in order to know if Eve's has been supplied instead. This is the reason some secure applications prompt you to accept the encryption key the first time and each time it changes.
$endgroup$
– Willtech
Feb 24 at 0:33
1
$begingroup$
@TVSuchty A certificate basically says "I am X, and you can trust that I am X because Y says so". Eve can easily create a certificate that says "I am Bob, and you can trust that I'm Bob because Eve says so". If my computer gets that certificate it just laughs. "Eve says so" is no reason to believe it's Bob's certificate. "Because Verisign says so", with Verisign being one of say 100 certificate providers that were installed on your computer by the manufacturer, that's a reason to believe it. But Eve can't forge such a certificate.
$endgroup$
– gnasher729
Feb 24 at 14:51
$begingroup$
Another answer to “why can’t eve send me bob’s certificate: “ Eve can either try to forge Bob’s certificate, or steal it. Maybe a million dollars is enough to bribe one of Bob’s employees to hand over a copy of Bob’s certificate. Bob has to make sure it’s hard to steal the certificate. If stolen, a certificate can be revoked and won’t be accepted anymore. The certificate will now say “this is a genuine certificate of Bob’s, but it was reported stolen, so don’t trust it”.
$endgroup$
– gnasher729
Feb 24 at 20:06
add a comment |
$begingroup$
In a man-in-the-middle attack, you ask Bob for his key but Eve intercepts the message and sends you her key instead. She asks Bob for his key and then passes messages between you and Bob, decrypting them, reading and/or changing them in the process.
The problem is that you don't know whether or not you really have Bob's key. Certificates get around this because the certification authority (CA) gives Bob a digitally signed message saying "Bob's key is 12345". You can verify this certificate because there aren't many CAs so your browser just contains a list of valid CA keys. Now, if Eve intercepts your attempt to start encrypted communication with Bob, she has two choices. If she tells you that Bob's key is 67890, then either she doesn't provide a certificate and you say "Sorry, you need to prove that" or she provides a fake certificate and you say "That certificate isn't valid." Alternatively, she tells you that Bob's key is 12345 and provides a valid certificate of that, but this is no use to her because she doesn't know Bob's private key, so she can't decrypt the messages she's relaying between the two of you.
answered Feb 23 at 11:31
David RicherbyDavid Richerby
67.7k15102193
$endgroup$
$begingroup$
Why Eve cannot just send me Bobs certificate? I mean what is special with Bob's key so that eve cannot replicate a similar one? How do I know that this key is a certified one? How do I verify the certificate?
$endgroup$
– TVSuchty
Feb 23 at 11:35
$begingroup$
I told you why she can't send you Bob's certificate (or, rather, why sending you Bob's certificate doesn't help her). There's no such thing as "a similar key". You know the key is certified because you have the certificate. You check the certificate by verifying the digital signature using the CA's key.
$endgroup$
– David Richerby
Feb 23 at 11:39
$begingroup$
@TVSuchty Eve must first decrypt the message to read it and then re-encrypt the message to pass it to on. Only Bob's private signing certificate will allow you to encrypt like Bob but the unfortunate person subject to the MITM attack must be able to prove if they have Bob's certificate in order to know if Eve's has been supplied instead. This is the reason some secure applications prompt you to accept the encryption key the first time and each time it changes.
$endgroup$
– Willtech
Feb 24 at 0:33
1
$begingroup$
@TVSuchty A certificate basically says "I am X, and you can trust that I am X because Y says so". Eve can easily create a certificate that says "I am Bob, and you can trust that I'm Bob because Eve says so". If my computer gets that certificate it just laughs. "Eve says so" is no reason to believe it's Bob's certificate. "Because Verisign says so", with Verisign being one of say 100 certificate providers that were installed on your computer by the manufacturer, that's a reason to believe it. But Eve can't forge such a certificate.
$endgroup$
– gnasher729
Feb 24 at 14:51
$begingroup$
Another answer to “why can’t eve send me bob’s certificate: “ Eve can either try to forge Bob’s certificate, or steal it. Maybe a million dollars is enough to bribe one of Bob’s employees to hand over a copy of Bob’s certificate. Bob has to make sure it’s hard to steal the certificate. If stolen, a certificate can be revoked and won’t be accepted anymore. The certificate will now say “this is a genuine certificate of Bob’s, but it was reported stolen, so don’t trust it”.
$endgroup$
– gnasher729
Feb 24 at 20:06
add a comment |
$begingroup$
In a man-in-the-middle attack, you ask Bob for his key but Eve intercepts the message and sends you her key instead. She asks Bob for his key and then passes messages between you and Bob, decrypting them, reading and/or changing them in the process.
The problem is that you don't know whether or not you really have Bob's key. Certificates get around this because the certification authority (CA) gives Bob a digitally signed message saying "Bob's key is 12345". You can verify this certificate because there aren't many CAs so your browser just contains a list of valid CA keys. Now, if Eve intercepts your attempt to start encrypted communication with Bob, she has two choices. If she tells you that Bob's key is 67890, then either she doesn't provide a certificate and you say "Sorry, you need to prove that" or she provides a fake certificate and you say "That certificate isn't valid." Alternatively, she tells you that Bob's key is 12345 and provides a valid certificate of that, but this is no use to her because she doesn't know Bob's private key, so she can't decrypt the messages she's relaying between the two of you.
answered Feb 23 at 11:31
David RicherbyDavid Richerby
67.7k15102193
$endgroup$
In a man-in-the-middle attack, you ask Bob for his key but Eve intercepts the message and sends you her key instead. She asks Bob for his key and then passes messages between you and Bob, decrypting them, reading and/or changing them in the process.
The problem is that you don't know whether or not you really have Bob's key. Certificates get around this because the certification authority (CA) gives Bob a digitally signed message saying "Bob's key is 12345". You can verify this certificate because there aren't many CAs so your browser just contains a list of valid CA keys. Now, if Eve intercepts your attempt to start encrypted communication with Bob, she has two choices. If she tells you that Bob's key is 67890, then either she doesn't provide a certificate and you say "Sorry, you need to prove that" or she provides a fake certificate and you say "That certificate isn't valid." Alternatively, she tells you that Bob's key is 12345 and provides a valid certificate of that, but this is no use to her because she doesn't know Bob's private key, so she can't decrypt the messages she's relaying between the two of you.
answered Feb 23 at 11:31
David RicherbyDavid Richerby
67.7k15102193
answered Feb 23 at 11:31
David RicherbyDavid Richerby
67.7k15102193
answered Feb 23 at 11:31
David RicherbyDavid Richerby
67.7k15102193
answered Feb 23 at 11:31
David RicherbyDavid Richerby
67.7k15102193
67.7k15102193
$begingroup$
Why Eve cannot just send me Bobs certificate? I mean what is special with Bob's key so that eve cannot replicate a similar one? How do I know that this key is a certified one? How do I verify the certificate?
$endgroup$
– TVSuchty
Feb 23 at 11:35
$begingroup$
I told you why she can't send you Bob's certificate (or, rather, why sending you Bob's certificate doesn't help her). There's no such thing as "a similar key". You know the key is certified because you have the certificate. You check the certificate by verifying the digital signature using the CA's key.
$endgroup$
– David Richerby
Feb 23 at 11:39
$begingroup$
@TVSuchty Eve must first decrypt the message to read it and then re-encrypt the message to pass it to on. Only Bob's private signing certificate will allow you to encrypt like Bob but the unfortunate person subject to the MITM attack must be able to prove if they have Bob's certificate in order to know if Eve's has been supplied instead. This is the reason some secure applications prompt you to accept the encryption key the first time and each time it changes.
$endgroup$
– Willtech
Feb 24 at 0:33
1
$begingroup$
@TVSuchty A certificate basically says "I am X, and you can trust that I am X because Y says so". Eve can easily create a certificate that says "I am Bob, and you can trust that I'm Bob because Eve says so". If my computer gets that certificate it just laughs. "Eve says so" is no reason to believe it's Bob's certificate. "Because Verisign says so", with Verisign being one of say 100 certificate providers that were installed on your computer by the manufacturer, that's a reason to believe it. But Eve can't forge such a certificate.
$endgroup$
– gnasher729
Feb 24 at 14:51
$begingroup$
Another answer to “why can’t eve send me bob’s certificate: “ Eve can either try to forge Bob’s certificate, or steal it. Maybe a million dollars is enough to bribe one of Bob’s employees to hand over a copy of Bob’s certificate. Bob has to make sure it’s hard to steal the certificate. If stolen, a certificate can be revoked and won’t be accepted anymore. The certificate will now say “this is a genuine certificate of Bob’s, but it was reported stolen, so don’t trust it”.
$endgroup$
– gnasher729
Feb 24 at 20:06
add a comment |
$begingroup$
Why Eve cannot just send me Bobs certificate? I mean what is special with Bob's key so that eve cannot replicate a similar one? How do I know that this key is a certified one? How do I verify the certificate?
$endgroup$
– TVSuchty
Feb 23 at 11:35
$begingroup$
I told you why she can't send you Bob's certificate (or, rather, why sending you Bob's certificate doesn't help her). There's no such thing as "a similar key". You know the key is certified because you have the certificate. You check the certificate by verifying the digital signature using the CA's key.
$endgroup$
– David Richerby
Feb 23 at 11:39
$begingroup$
@TVSuchty Eve must first decrypt the message to read it and then re-encrypt the message to pass it to on. Only Bob's private signing certificate will allow you to encrypt like Bob but the unfortunate person subject to the MITM attack must be able to prove if they have Bob's certificate in order to know if Eve's has been supplied instead. This is the reason some secure applications prompt you to accept the encryption key the first time and each time it changes.
$endgroup$
– Willtech
Feb 24 at 0:33
1
$begingroup$
@TVSuchty A certificate basically says "I am X, and you can trust that I am X because Y says so". Eve can easily create a certificate that says "I am Bob, and you can trust that I'm Bob because Eve says so". If my computer gets that certificate it just laughs. "Eve says so" is no reason to believe it's Bob's certificate. "Because Verisign says so", with Verisign being one of say 100 certificate providers that were installed on your computer by the manufacturer, that's a reason to believe it. But Eve can't forge such a certificate.
$endgroup$
– gnasher729
Feb 24 at 14:51
$begingroup$
Another answer to “why can’t eve send me bob’s certificate: “ Eve can either try to forge Bob’s certificate, or steal it. Maybe a million dollars is enough to bribe one of Bob’s employees to hand over a copy of Bob’s certificate. Bob has to make sure it’s hard to steal the certificate. If stolen, a certificate can be revoked and won’t be accepted anymore. The certificate will now say “this is a genuine certificate of Bob’s, but it was reported stolen, so don’t trust it”.
$endgroup$
– gnasher729
Feb 24 at 20:06
$begingroup$
Why Eve cannot just send me Bobs certificate? I mean what is special with Bob's key so that eve cannot replicate a similar one? How do I know that this key is a certified one? How do I verify the certificate?
$endgroup$
– TVSuchty
Feb 23 at 11:35
$begingroup$
Why Eve cannot just send me Bobs certificate? I mean what is special with Bob's key so that eve cannot replicate a similar one? How do I know that this key is a certified one? How do I verify the certificate?
$endgroup$
– TVSuchty
Feb 23 at 11:35
$begingroup$
I told you why she can't send you Bob's certificate (or, rather, why sending you Bob's certificate doesn't help her). There's no such thing as "a similar key". You know the key is certified because you have the certificate. You check the certificate by verifying the digital signature using the CA's key.
$endgroup$
– David Richerby
Feb 23 at 11:39
$begingroup$
I told you why she can't send you Bob's certificate (or, rather, why sending you Bob's certificate doesn't help her). There's no such thing as "a similar key". You know the key is certified because you have the certificate. You check the certificate by verifying the digital signature using the CA's key.
$endgroup$
– David Richerby
Feb 23 at 11:39
$begingroup$
@TVSuchty Eve must first decrypt the message to read it and then re-encrypt the message to pass it to on. Only Bob's private signing certificate will allow you to encrypt like Bob but the unfortunate person subject to the MITM attack must be able to prove if they have Bob's certificate in order to know if Eve's has been supplied instead. This is the reason some secure applications prompt you to accept the encryption key the first time and each time it changes.
$endgroup$
– Willtech
Feb 24 at 0:33
$begingroup$
@TVSuchty Eve must first decrypt the message to read it and then re-encrypt the message to pass it to on. Only Bob's private signing certificate will allow you to encrypt like Bob but the unfortunate person subject to the MITM attack must be able to prove if they have Bob's certificate in order to know if Eve's has been supplied instead. This is the reason some secure applications prompt you to accept the encryption key the first time and each time it changes.
$endgroup$
– Willtech
Feb 24 at 0:33
1
1
$begingroup$
@TVSuchty A certificate basically says "I am X, and you can trust that I am X because Y says so". Eve can easily create a certificate that says "I am Bob, and you can trust that I'm Bob because Eve says so". If my computer gets that certificate it just laughs. "Eve says so" is no reason to believe it's Bob's certificate. "Because Verisign says so", with Verisign being one of say 100 certificate providers that were installed on your computer by the manufacturer, that's a reason to believe it. But Eve can't forge such a certificate.
$endgroup$
– gnasher729
Feb 24 at 14:51
$begingroup$
@TVSuchty A certificate basically says "I am X, and you can trust that I am X because Y says so". Eve can easily create a certificate that says "I am Bob, and you can trust that I'm Bob because Eve says so". If my computer gets that certificate it just laughs. "Eve says so" is no reason to believe it's Bob's certificate. "Because Verisign says so", with Verisign being one of say 100 certificate providers that were installed on your computer by the manufacturer, that's a reason to believe it. But Eve can't forge such a certificate.
$endgroup$
– gnasher729
Feb 24 at 14:51
$begingroup$
Another answer to “why can’t eve send me bob’s certificate: “ Eve can either try to forge Bob’s certificate, or steal it. Maybe a million dollars is enough to bribe one of Bob’s employees to hand over a copy of Bob’s certificate. Bob has to make sure it’s hard to steal the certificate. If stolen, a certificate can be revoked and won’t be accepted anymore. The certificate will now say “this is a genuine certificate of Bob’s, but it was reported stolen, so don’t trust it”.
$endgroup$
– gnasher729
Feb 24 at 20:06
$begingroup$
Another answer to “why can’t eve send me bob’s certificate: “ Eve can either try to forge Bob’s certificate, or steal it. Maybe a million dollars is enough to bribe one of Bob’s employees to hand over a copy of Bob’s certificate. Bob has to make sure it’s hard to steal the certificate. If stolen, a certificate can be revoked and won’t be accepted anymore. The certificate will now say “this is a genuine certificate of Bob’s, but it was reported stolen, so don’t trust it”.
$endgroup$
– gnasher729
Feb 24 at 20:06
add a comment |
Thanks for contributing an answer to Computer Science Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
Use MathJax to format equations. MathJax reference.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcs.stackexchange.com%2fquestions%2f104745%2fcan-you-prevent-a-man-in-the-middle-from-reading-the-message%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
