Can you prevent a man in the middle from reading the message?Can the Bell-LaPadula model emulate the Chinese...
Missing a connection and don't have money to book next flight
Buying a "Used" Router
Will the duration of traveling to Ceres using the same tech developed for going to Mars be proportional to the distance to go to Mars or not?
Why aren't passengers instructed how to lift aisle armrests?
Are one-line email responses considered disrespectful?
Can you prevent a man in the middle from reading the message?
Boss asked me to sign a resignation paper without a date on it along with my new contract
How do I avoid the "chosen hero" feeling?
Why don't programs completely uninstall (remove all their files) when I remove them?
Create a line break in a subscript-position term
How can I handle players killing my NPC outside of combat?
Sets that are both Sum-free and Product-free
How can I give a Ranger advantage on a check due to Favored Enemy without spoiling the story for the player?
Why do single electrical receptacles exist?
Is layered encryption more secure than long passwords?
Sing Baby Shark
Is there redundancy between a US Passport Card and an Enhanced Driver's License?
What is the meaning of "usr"?
What is wrong with my use of "find -print0"?
Minimum Viable Product for RTS game?
Is there any danger of my neighbor having my wife's signature?
What really causes series inductance of capacitors?
My job requires me to shuck oysters
Is it possible to detect 100% of SQLi with a simple regex?
Can you prevent a man in the middle from reading the message?
Can the Bell-LaPadula model emulate the Chinese Wall model?Could program verification techniques prevent bugs of the genre of Heartbleed from occurring?Would limiting the number of operations in a transaction prevent SQL injection?How can a usage message or non-trappable key sequence defeat a Trojan horse attack?
$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?
security
New contributor
$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?
security
New contributor
$endgroup$
$begingroup$
Generally, an authenticated key exchange over an insecure channel subsumes the existence of an alternative, trusted channel such as a PKI.
$endgroup$
– dkaeae
30 mins ago
$begingroup$
There's no such thing as "fudging a digital signature".
$endgroup$
– David Richerby
20 mins ago
$begingroup$
Why? I am fudging the certificate, the man in the middle got?
$endgroup$
– TVSuchty
16 mins ago
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?
security
New contributor
$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?
security
security
New contributor
New contributor
edited 18 mins ago
TVSuchty
New contributor
asked 56 mins ago
TVSuchtyTVSuchty
83
83
New contributor
New contributor
$begingroup$
Generally, an authenticated key exchange over an insecure channel subsumes the existence of an alternative, trusted channel such as a PKI.
$endgroup$
– dkaeae
30 mins ago
$begingroup$
There's no such thing as "fudging a digital signature".
$endgroup$
– David Richerby
20 mins ago
$begingroup$
Why? I am fudging the certificate, the man in the middle got?
$endgroup$
– TVSuchty
16 mins ago
add a comment |
$begingroup$
Generally, an authenticated key exchange over an insecure channel subsumes the existence of an alternative, trusted channel such as a PKI.
$endgroup$
– dkaeae
30 mins ago
$begingroup$
There's no such thing as "fudging a digital signature".
$endgroup$
– David Richerby
20 mins ago
$begingroup$
Why? I am fudging the certificate, the man in the middle got?
$endgroup$
– TVSuchty
16 mins ago
$begingroup$
Generally, an authenticated key exchange over an insecure channel subsumes the existence of an alternative, trusted channel such as a PKI.
$endgroup$
– dkaeae
30 mins ago
$begingroup$
Generally, an authenticated key exchange over an insecure channel subsumes the existence of an alternative, trusted channel such as a PKI.
$endgroup$
– dkaeae
30 mins ago
$begingroup$
There's no such thing as "fudging a digital signature".
$endgroup$
– David Richerby
20 mins ago
$begingroup$
There's no such thing as "fudging a digital signature".
$endgroup$
– David Richerby
20 mins ago
$begingroup$
Why? I am fudging the certificate, the man in the middle got?
$endgroup$
– TVSuchty
16 mins ago
$begingroup$
Why? I am fudging the certificate, the man in the middle got?
$endgroup$
– TVSuchty
16 mins ago
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).
$endgroup$
$begingroup$
So we are basically communicating the certificates through a second channel, we know to be secure?
$endgroup$
– TVSuchty
18 mins ago
$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
16 mins ago
$begingroup$
But why would not we talk about the channel, we know to be secure, in the first place?
$endgroup$
– TVSuchty
15 mins ago
$begingroup$
If we could, we would. The problem is these channels are either impracticable (imagine having to drive to an HTTP server to obtain a webpage or dictating someone a 8MB PDF file over the phone) or unable to convey information both ways (which is the case for a PKI).
$endgroup$
– dkaeae
12 mins ago
$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
10 mins ago
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.
$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
26 mins ago
$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
22 mins ago
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
});
}
});
TVSuchty is a new contributor. Be nice, and check out our Code of Conduct.
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).
$endgroup$
$begingroup$
So we are basically communicating the certificates through a second channel, we know to be secure?
$endgroup$
– TVSuchty
18 mins ago
$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
16 mins ago
$begingroup$
But why would not we talk about the channel, we know to be secure, in the first place?
$endgroup$
– TVSuchty
15 mins ago
$begingroup$
If we could, we would. The problem is these channels are either impracticable (imagine having to drive to an HTTP server to obtain a webpage or dictating someone a 8MB PDF file over the phone) or unable to convey information both ways (which is the case for a PKI).
$endgroup$
– dkaeae
12 mins ago
$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
10 mins ago
add a comment |
$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).
$endgroup$
$begingroup$
So we are basically communicating the certificates through a second channel, we know to be secure?
$endgroup$
– TVSuchty
18 mins ago
$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
16 mins ago
$begingroup$
But why would not we talk about the channel, we know to be secure, in the first place?
$endgroup$
– TVSuchty
15 mins ago
$begingroup$
If we could, we would. The problem is these channels are either impracticable (imagine having to drive to an HTTP server to obtain a webpage or dictating someone a 8MB PDF file over the phone) or unable to convey information both ways (which is the case for a PKI).
$endgroup$
– dkaeae
12 mins ago
$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
10 mins ago
add a comment |
$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).
$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).
edited 15 mins ago
answered 23 mins ago
dkaeaedkaeae
1,693721
1,693721
$begingroup$
So we are basically communicating the certificates through a second channel, we know to be secure?
$endgroup$
– TVSuchty
18 mins ago
$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
16 mins ago
$begingroup$
But why would not we talk about the channel, we know to be secure, in the first place?
$endgroup$
– TVSuchty
15 mins ago
$begingroup$
If we could, we would. The problem is these channels are either impracticable (imagine having to drive to an HTTP server to obtain a webpage or dictating someone a 8MB PDF file over the phone) or unable to convey information both ways (which is the case for a PKI).
$endgroup$
– dkaeae
12 mins ago
$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
10 mins ago
add a comment |
$begingroup$
So we are basically communicating the certificates through a second channel, we know to be secure?
$endgroup$
– TVSuchty
18 mins ago
$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
16 mins ago
$begingroup$
But why would not we talk about the channel, we know to be secure, in the first place?
$endgroup$
– TVSuchty
15 mins ago
$begingroup$
If we could, we would. The problem is these channels are either impracticable (imagine having to drive to an HTTP server to obtain a webpage or dictating someone a 8MB PDF file over the phone) or unable to convey information both ways (which is the case for a PKI).
$endgroup$
– dkaeae
12 mins ago
$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
10 mins ago
$begingroup$
So we are basically communicating the certificates through a second channel, we know to be secure?
$endgroup$
– TVSuchty
18 mins ago
$begingroup$
So we are basically communicating the certificates through a second channel, we know to be secure?
$endgroup$
– TVSuchty
18 mins ago
$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
16 mins ago
$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
16 mins ago
$begingroup$
But why would not we talk about the channel, we know to be secure, in the first place?
$endgroup$
– TVSuchty
15 mins ago
$begingroup$
But why would not we talk about the channel, we know to be secure, in the first place?
$endgroup$
– TVSuchty
15 mins ago
$begingroup$
If we could, we would. The problem is these channels are either impracticable (imagine having to drive to an HTTP server to obtain a webpage or dictating someone a 8MB PDF file over the phone) or unable to convey information both ways (which is the case for a PKI).
$endgroup$
– dkaeae
12 mins ago
$begingroup$
If we could, we would. The problem is these channels are either impracticable (imagine having to drive to an HTTP server to obtain a webpage or dictating someone a 8MB PDF file over the phone) or unable to convey information both ways (which is the case for a PKI).
$endgroup$
– dkaeae
12 mins ago
$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
10 mins ago
$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
10 mins ago
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.
$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
26 mins ago
$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
22 mins ago
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.
$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
26 mins ago
$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
22 mins ago
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.
$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 31 mins ago
David RicherbyDavid Richerby
67.5k15102193
67.5k15102193
$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
26 mins ago
$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
22 mins ago
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
26 mins ago
$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
22 mins ago
$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
26 mins ago
$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
26 mins ago
$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
22 mins ago
$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
22 mins ago
add a comment |
TVSuchty is a new contributor. Be nice, and check out our Code of Conduct.
TVSuchty is a new contributor. Be nice, and check out our Code of Conduct.
TVSuchty is a new contributor. Be nice, and check out our Code of Conduct.
TVSuchty is a new contributor. Be nice, and check out our Code of Conduct.
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
$begingroup$
Generally, an authenticated key exchange over an insecure channel subsumes the existence of an alternative, trusted channel such as a PKI.
$endgroup$
– dkaeae
30 mins ago
$begingroup$
There's no such thing as "fudging a digital signature".
$endgroup$
– David Richerby
20 mins ago
$begingroup$
Why? I am fudging the certificate, the man in the middle got?
$endgroup$
– TVSuchty
16 mins ago