Read SSL and TLS data in HTTPS traffic
Is it possible to parse and store SSL and TLS data without decryption? Not the http headers which are encrypted but the data that is available without decryption? I see that Wireshark is able to present this data, but I dont know how/what approach to follow. I have successfully parsed HTTP traffic but am unable to do the same for HTTPS. The data I am talking about is the following:
Can this be achieved?
I have the following code that captures traffic on port 443 and further forwards it to print the data like it does for my HTTP traffic on port 80.
payload = (u_char *)(packet + SIZE_ETHERNET + size_ip + size_tcp);
/* Compute tcp payload (segment) size */
size_payload = ntohs(ip->ip_len) - (size_ip + size_tcp);
printf("%s:", inet_ntoa(ip->ip_src));
printf("n");
printf("%d ", ntohs(tcp->th_sport));
printf("n");
printf("%s:", inet_ntoa(ip->ip_dst));
printf("n");
printf("%d ", ntohs(tcp->th_dport));
printf("n");
if (ntohs(tcp->th_sport) == 443)
{
printf("Payload:- ");
print_payload(payload, size_payload);
}
else if (ntohs(tcp->th_dport) == 443)
{
printf("Payload:- ");
print_payload(payload, size_payload);
}
The HTTP traffic prints just right, but in this case the output is all jumbled up characters.
Output:
52.114.128.9
443
10.8.25.7
55605
Payload:- ]4=]?).-`9)}e`B_.Zp*$'AJ}/)K.P;7%-=1dV2qN,fxU?A2{h;/TEi7("Bc`;Op<?TS8O]WhX_D]O<Zi*}aGg~`@ff)3!i[ieYm(-/JP'"+kOHNwmE 3jZBX[*y`{OR9w'!1SM
I'd be grateful if somebody could help me get through this, or atleast point me to a direction where I could work it out. Thanks in advance
c ssl https packet-capture
asked Nov 26 '18 at 10:30
Devanshu MisraDevanshu Misra
500518
add a comment |
Is it possible to parse and store SSL and TLS data without decryption? Not the http headers which are encrypted but the data that is available without decryption? I see that Wireshark is able to present this data, but I dont know how/what approach to follow. I have successfully parsed HTTP traffic but am unable to do the same for HTTPS. The data I am talking about is the following:
Can this be achieved?
I have the following code that captures traffic on port 443 and further forwards it to print the data like it does for my HTTP traffic on port 80.
payload = (u_char *)(packet + SIZE_ETHERNET + size_ip + size_tcp);
/* Compute tcp payload (segment) size */
size_payload = ntohs(ip->ip_len) - (size_ip + size_tcp);
printf("%s:", inet_ntoa(ip->ip_src));
printf("n");
printf("%d ", ntohs(tcp->th_sport));
printf("n");
printf("%s:", inet_ntoa(ip->ip_dst));
printf("n");
printf("%d ", ntohs(tcp->th_dport));
printf("n");
if (ntohs(tcp->th_sport) == 443)
{
printf("Payload:- ");
print_payload(payload, size_payload);
}
else if (ntohs(tcp->th_dport) == 443)
{
printf("Payload:- ");
print_payload(payload, size_payload);
}
The HTTP traffic prints just right, but in this case the output is all jumbled up characters.
Output:
52.114.128.9
443
10.8.25.7
55605
Payload:- ]4=]?).-`9)}e`B_.Zp*$'AJ}/)K.P;7%-=1dV2qN,fxU?A2{h;/TEi7("Bc`;Op<?TS8O]WhX_D]O<Zi*}aGg~`@ff)3!i[ieYm(-/JP'"+kOHNwmE 3jZBX[*y`{OR9w'!1SM
I'd be grateful if somebody could help me get through this, or atleast point me to a direction where I could work it out. Thanks in advance
c ssl https packet-capture
asked Nov 26 '18 at 10:30
Devanshu MisraDevanshu Misra
500518
I'm not sure what you are trying to do. The application payload (HTTP) is of course encrypted and you cannot get it. What you see in wireshark are TLS layer information, i.e. certificate, key exchange, offered ciphers, used protocol version ... . They can be extracted by parsing the TLS records according to the specification which you can find in the TLS standards.
– Steffen Ullrich
Nov 26 '18 at 12:09
"Is it possible to parse and store SSL and TLS data without decryption?" Imagine if anyone could do that, don't you think that it would break TLS guarantee on integrity and confidentiality of exchanges, and mean that everyone would be able to read anyone's web traffic, including to banks, personal accounts, health related activity, etc. hence defeating the very true core nature of TLS? Besides the few first handshake messages (with TLS 1.3 far more are encrypted), everything else (HTTP headers and content) is encrypted, using a key negotiated during handshake.
– Patrick Mevzek
Nov 26 '18 at 15:44
@SteffenUllrich Thanks for the link. I'll check it out and update you guys on the same. Also, I don't want the application payload since it hampers with the integrity and confidentiality provided by the Encrypted HTTPS communication. Thanks again for the insight.
– Devanshu Misra
Nov 27 '18 at 7:09
@PatrickMevzek I think you misunderstood my question. I wanted the TLS Layer Information as I have mentioned in the question and the screenshot posted above. Not the encrypted data. I am building a network monitoring application and not a sniffer to hack public data. I'm sorry for the misunderstanding and would try to be more precise and clear about my queries. Thank you for pointing it out.
– Devanshu Misra
Nov 27 '18 at 7:12
add a comment |
Is it possible to parse and store SSL and TLS data without decryption? Not the http headers which are encrypted but the data that is available without decryption? I see that Wireshark is able to present this data, but I dont know how/what approach to follow. I have successfully parsed HTTP traffic but am unable to do the same for HTTPS. The data I am talking about is the following:
Can this be achieved?
I have the following code that captures traffic on port 443 and further forwards it to print the data like it does for my HTTP traffic on port 80.
payload = (u_char *)(packet + SIZE_ETHERNET + size_ip + size_tcp);
/* Compute tcp payload (segment) size */
size_payload = ntohs(ip->ip_len) - (size_ip + size_tcp);
printf("%s:", inet_ntoa(ip->ip_src));
printf("n");
printf("%d ", ntohs(tcp->th_sport));
printf("n");
printf("%s:", inet_ntoa(ip->ip_dst));
printf("n");
printf("%d ", ntohs(tcp->th_dport));
printf("n");
if (ntohs(tcp->th_sport) == 443)
{
printf("Payload:- ");
print_payload(payload, size_payload);
}
else if (ntohs(tcp->th_dport) == 443)
{
printf("Payload:- ");
print_payload(payload, size_payload);
}
The HTTP traffic prints just right, but in this case the output is all jumbled up characters.
Output:
52.114.128.9
443
10.8.25.7
55605
Payload:- ]4=]?).-`9)}e`B_.Zp*$'AJ}/)K.P;7%-=1dV2qN,fxU?A2{h;/TEi7("Bc`;Op<?TS8O]WhX_D]O<Zi*}aGg~`@ff)3!i[ieYm(-/JP'"+kOHNwmE 3jZBX[*y`{OR9w'!1SM
I'd be grateful if somebody could help me get through this, or atleast point me to a direction where I could work it out. Thanks in advance
c ssl https packet-capture
asked Nov 26 '18 at 10:30
Devanshu MisraDevanshu Misra
500518
Is it possible to parse and store SSL and TLS data without decryption? Not the http headers which are encrypted but the data that is available without decryption? I see that Wireshark is able to present this data, but I dont know how/what approach to follow. I have successfully parsed HTTP traffic but am unable to do the same for HTTPS. The data I am talking about is the following:
Can this be achieved?
I have the following code that captures traffic on port 443 and further forwards it to print the data like it does for my HTTP traffic on port 80.
payload = (u_char *)(packet + SIZE_ETHERNET + size_ip + size_tcp);
/* Compute tcp payload (segment) size */
size_payload = ntohs(ip->ip_len) - (size_ip + size_tcp);
printf("%s:", inet_ntoa(ip->ip_src));
printf("n");
printf("%d ", ntohs(tcp->th_sport));
printf("n");
printf("%s:", inet_ntoa(ip->ip_dst));
printf("n");
printf("%d ", ntohs(tcp->th_dport));
printf("n");
if (ntohs(tcp->th_sport) == 443)
{
printf("Payload:- ");
print_payload(payload, size_payload);
}
else if (ntohs(tcp->th_dport) == 443)
{
printf("Payload:- ");
print_payload(payload, size_payload);
}
The HTTP traffic prints just right, but in this case the output is all jumbled up characters.
Output:
52.114.128.9
443
10.8.25.7
55605
Payload:- ]4=]?).-`9)}e`B_.Zp*$'AJ}/)K.P;7%-=1dV2qN,fxU?A2{h;/TEi7("Bc`;Op<?TS8O]WhX_D]O<Zi*}aGg~`@ff)3!i[ieYm(-/JP'"+kOHNwmE 3jZBX[*y`{OR9w'!1SM
I'd be grateful if somebody could help me get through this, or atleast point me to a direction where I could work it out. Thanks in advance
c ssl https packet-capture
c ssl https packet-capture
asked Nov 26 '18 at 10:30
Devanshu MisraDevanshu Misra
500518
asked Nov 26 '18 at 10:30
Devanshu MisraDevanshu Misra
500518
asked Nov 26 '18 at 10:30
Devanshu MisraDevanshu Misra
500518
asked Nov 26 '18 at 10:30
Devanshu MisraDevanshu Misra
500518
asked Nov 26 '18 at 10:30
Devanshu MisraDevanshu Misra
500518
500518
I'm not sure what you are trying to do. The application payload (HTTP) is of course encrypted and you cannot get it. What you see in wireshark are TLS layer information, i.e. certificate, key exchange, offered ciphers, used protocol version ... . They can be extracted by parsing the TLS records according to the specification which you can find in the TLS standards.
– Steffen Ullrich
Nov 26 '18 at 12:09
"Is it possible to parse and store SSL and TLS data without decryption?" Imagine if anyone could do that, don't you think that it would break TLS guarantee on integrity and confidentiality of exchanges, and mean that everyone would be able to read anyone's web traffic, including to banks, personal accounts, health related activity, etc. hence defeating the very true core nature of TLS? Besides the few first handshake messages (with TLS 1.3 far more are encrypted), everything else (HTTP headers and content) is encrypted, using a key negotiated during handshake.
– Patrick Mevzek
Nov 26 '18 at 15:44
@SteffenUllrich Thanks for the link. I'll check it out and update you guys on the same. Also, I don't want the application payload since it hampers with the integrity and confidentiality provided by the Encrypted HTTPS communication. Thanks again for the insight.
– Devanshu Misra
Nov 27 '18 at 7:09
@PatrickMevzek I think you misunderstood my question. I wanted the TLS Layer Information as I have mentioned in the question and the screenshot posted above. Not the encrypted data. I am building a network monitoring application and not a sniffer to hack public data. I'm sorry for the misunderstanding and would try to be more precise and clear about my queries. Thank you for pointing it out.
– Devanshu Misra
Nov 27 '18 at 7:12
add a comment |
I'm not sure what you are trying to do. The application payload (HTTP) is of course encrypted and you cannot get it. What you see in wireshark are TLS layer information, i.e. certificate, key exchange, offered ciphers, used protocol version ... . They can be extracted by parsing the TLS records according to the specification which you can find in the TLS standards.
– Steffen Ullrich
Nov 26 '18 at 12:09
"Is it possible to parse and store SSL and TLS data without decryption?" Imagine if anyone could do that, don't you think that it would break TLS guarantee on integrity and confidentiality of exchanges, and mean that everyone would be able to read anyone's web traffic, including to banks, personal accounts, health related activity, etc. hence defeating the very true core nature of TLS? Besides the few first handshake messages (with TLS 1.3 far more are encrypted), everything else (HTTP headers and content) is encrypted, using a key negotiated during handshake.
– Patrick Mevzek
Nov 26 '18 at 15:44
@SteffenUllrich Thanks for the link. I'll check it out and update you guys on the same. Also, I don't want the application payload since it hampers with the integrity and confidentiality provided by the Encrypted HTTPS communication. Thanks again for the insight.
– Devanshu Misra
Nov 27 '18 at 7:09
@PatrickMevzek I think you misunderstood my question. I wanted the TLS Layer Information as I have mentioned in the question and the screenshot posted above. Not the encrypted data. I am building a network monitoring application and not a sniffer to hack public data. I'm sorry for the misunderstanding and would try to be more precise and clear about my queries. Thank you for pointing it out.
– Devanshu Misra
Nov 27 '18 at 7:12
I'm not sure what you are trying to do. The application payload (HTTP) is of course encrypted and you cannot get it. What you see in wireshark are TLS layer information, i.e. certificate, key exchange, offered ciphers, used protocol version ... . They can be extracted by parsing the TLS records according to the specification which you can find in the TLS standards.
– Steffen Ullrich
Nov 26 '18 at 12:09
I'm not sure what you are trying to do. The application payload (HTTP) is of course encrypted and you cannot get it. What you see in wireshark are TLS layer information, i.e. certificate, key exchange, offered ciphers, used protocol version ... . They can be extracted by parsing the TLS records according to the specification which you can find in the TLS standards.
– Steffen Ullrich
Nov 26 '18 at 12:09
"Is it possible to parse and store SSL and TLS data without decryption?" Imagine if anyone could do that, don't you think that it would break TLS guarantee on integrity and confidentiality of exchanges, and mean that everyone would be able to read anyone's web traffic, including to banks, personal accounts, health related activity, etc. hence defeating the very true core nature of TLS? Besides the few first handshake messages (with TLS 1.3 far more are encrypted), everything else (HTTP headers and content) is encrypted, using a key negotiated during handshake.
– Patrick Mevzek
Nov 26 '18 at 15:44
"Is it possible to parse and store SSL and TLS data without decryption?" Imagine if anyone could do that, don't you think that it would break TLS guarantee on integrity and confidentiality of exchanges, and mean that everyone would be able to read anyone's web traffic, including to banks, personal accounts, health related activity, etc. hence defeating the very true core nature of TLS? Besides the few first handshake messages (with TLS 1.3 far more are encrypted), everything else (HTTP headers and content) is encrypted, using a key negotiated during handshake.
– Patrick Mevzek
Nov 26 '18 at 15:44
@SteffenUllrich Thanks for the link. I'll check it out and update you guys on the same. Also, I don't want the application payload since it hampers with the integrity and confidentiality provided by the Encrypted HTTPS communication. Thanks again for the insight.
– Devanshu Misra
Nov 27 '18 at 7:09
@SteffenUllrich Thanks for the link. I'll check it out and update you guys on the same. Also, I don't want the application payload since it hampers with the integrity and confidentiality provided by the Encrypted HTTPS communication. Thanks again for the insight.
– Devanshu Misra
Nov 27 '18 at 7:09
@PatrickMevzek I think you misunderstood my question. I wanted the TLS Layer Information as I have mentioned in the question and the screenshot posted above. Not the encrypted data. I am building a network monitoring application and not a sniffer to hack public data. I'm sorry for the misunderstanding and would try to be more precise and clear about my queries. Thank you for pointing it out.
– Devanshu Misra
Nov 27 '18 at 7:12
@PatrickMevzek I think you misunderstood my question. I wanted the TLS Layer Information as I have mentioned in the question and the screenshot posted above. Not the encrypted data. I am building a network monitoring application and not a sniffer to hack public data. I'm sorry for the misunderstanding and would try to be more precise and clear about my queries. Thank you for pointing it out.
– Devanshu Misra
Nov 27 '18 at 7:12
add a comment |
1 Answer
1
active
oldest
votes
TLS builds on TCP which provides host-to-host connectivity at the transport layer (layer 4). This means that you can always parse layer 4 and lower information (such as IP or TCP) since it is not protected by TLS at all.
Above layer 4, you can see (and parse) the unencrypted TLS handshake that initiates the encryption connection (*). Afterwards, all data above layer 4 is encrypted and you can only see what appears to be random data. Since HTTP lives above layer 4, you should never see any unencrypted HTTP traffic.
(*) TLS 1.3 encrypts part of the handshake. See this answer.
answered Nov 26 '18 at 17:48
inorikinorik
386
Oh, I did not know that that TLS 1.3 encrypts part of the handshake as well. Thanks for the this. Also, are there any predefined structs I can use to parse the TLS layer information? It is pretty difficult to read an RFC and follow its standards. But I'll try to do that till I find something simpler to work on(or a link that provides pre built struct to store this information without thinking and then creating ones on my own)
– Devanshu Misra
Nov 27 '18 at 7:15
Wireshark or its command line variant 'tshark' can provide protocol dissection for you so you do not have to parse raw traffic yourself. If you want a more accessible explanation of the details of TLS, have a look at this illustration: tls.ulfheim.net
– inorik
Nov 27 '18 at 19:30
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
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: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
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%2fstackoverflow.com%2fquestions%2f53479172%2fread-ssl-and-tls-data-in-https-traffic%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
TLS builds on TCP which provides host-to-host connectivity at the transport layer (layer 4). This means that you can always parse layer 4 and lower information (such as IP or TCP) since it is not protected by TLS at all.
Above layer 4, you can see (and parse) the unencrypted TLS handshake that initiates the encryption connection (*). Afterwards, all data above layer 4 is encrypted and you can only see what appears to be random data. Since HTTP lives above layer 4, you should never see any unencrypted HTTP traffic.
(*) TLS 1.3 encrypts part of the handshake. See this answer.
answered Nov 26 '18 at 17:48
inorikinorik
386
Oh, I did not know that that TLS 1.3 encrypts part of the handshake as well. Thanks for the this. Also, are there any predefined structs I can use to parse the TLS layer information? It is pretty difficult to read an RFC and follow its standards. But I'll try to do that till I find something simpler to work on(or a link that provides pre built struct to store this information without thinking and then creating ones on my own)
– Devanshu Misra
Nov 27 '18 at 7:15
Wireshark or its command line variant 'tshark' can provide protocol dissection for you so you do not have to parse raw traffic yourself. If you want a more accessible explanation of the details of TLS, have a look at this illustration: tls.ulfheim.net
– inorik
Nov 27 '18 at 19:30
add a comment |
TLS builds on TCP which provides host-to-host connectivity at the transport layer (layer 4). This means that you can always parse layer 4 and lower information (such as IP or TCP) since it is not protected by TLS at all.
Above layer 4, you can see (and parse) the unencrypted TLS handshake that initiates the encryption connection (*). Afterwards, all data above layer 4 is encrypted and you can only see what appears to be random data. Since HTTP lives above layer 4, you should never see any unencrypted HTTP traffic.
(*) TLS 1.3 encrypts part of the handshake. See this answer.
answered Nov 26 '18 at 17:48
inorikinorik
386
Oh, I did not know that that TLS 1.3 encrypts part of the handshake as well. Thanks for the this. Also, are there any predefined structs I can use to parse the TLS layer information? It is pretty difficult to read an RFC and follow its standards. But I'll try to do that till I find something simpler to work on(or a link that provides pre built struct to store this information without thinking and then creating ones on my own)
– Devanshu Misra
Nov 27 '18 at 7:15
Wireshark or its command line variant 'tshark' can provide protocol dissection for you so you do not have to parse raw traffic yourself. If you want a more accessible explanation of the details of TLS, have a look at this illustration: tls.ulfheim.net
– inorik
Nov 27 '18 at 19:30
add a comment |
TLS builds on TCP which provides host-to-host connectivity at the transport layer (layer 4). This means that you can always parse layer 4 and lower information (such as IP or TCP) since it is not protected by TLS at all.
Above layer 4, you can see (and parse) the unencrypted TLS handshake that initiates the encryption connection (*). Afterwards, all data above layer 4 is encrypted and you can only see what appears to be random data. Since HTTP lives above layer 4, you should never see any unencrypted HTTP traffic.
(*) TLS 1.3 encrypts part of the handshake. See this answer.
answered Nov 26 '18 at 17:48
inorikinorik
386
TLS builds on TCP which provides host-to-host connectivity at the transport layer (layer 4). This means that you can always parse layer 4 and lower information (such as IP or TCP) since it is not protected by TLS at all.
Above layer 4, you can see (and parse) the unencrypted TLS handshake that initiates the encryption connection (*). Afterwards, all data above layer 4 is encrypted and you can only see what appears to be random data. Since HTTP lives above layer 4, you should never see any unencrypted HTTP traffic.
(*) TLS 1.3 encrypts part of the handshake. See this answer.
answered Nov 26 '18 at 17:48
inorikinorik
386
answered Nov 26 '18 at 17:48
inorikinorik
386
answered Nov 26 '18 at 17:48
inorikinorik
386
answered Nov 26 '18 at 17:48
inorikinorik
386
386
Oh, I did not know that that TLS 1.3 encrypts part of the handshake as well. Thanks for the this. Also, are there any predefined structs I can use to parse the TLS layer information? It is pretty difficult to read an RFC and follow its standards. But I'll try to do that till I find something simpler to work on(or a link that provides pre built struct to store this information without thinking and then creating ones on my own)
– Devanshu Misra
Nov 27 '18 at 7:15
Wireshark or its command line variant 'tshark' can provide protocol dissection for you so you do not have to parse raw traffic yourself. If you want a more accessible explanation of the details of TLS, have a look at this illustration: tls.ulfheim.net
– inorik
Nov 27 '18 at 19:30
add a comment |
Oh, I did not know that that TLS 1.3 encrypts part of the handshake as well. Thanks for the this. Also, are there any predefined structs I can use to parse the TLS layer information? It is pretty difficult to read an RFC and follow its standards. But I'll try to do that till I find something simpler to work on(or a link that provides pre built struct to store this information without thinking and then creating ones on my own)
– Devanshu Misra
Nov 27 '18 at 7:15
Wireshark or its command line variant 'tshark' can provide protocol dissection for you so you do not have to parse raw traffic yourself. If you want a more accessible explanation of the details of TLS, have a look at this illustration: tls.ulfheim.net
– inorik
Nov 27 '18 at 19:30
Oh, I did not know that that TLS 1.3 encrypts part of the handshake as well. Thanks for the this. Also, are there any predefined structs I can use to parse the TLS layer information? It is pretty difficult to read an RFC and follow its standards. But I'll try to do that till I find something simpler to work on(or a link that provides pre built struct to store this information without thinking and then creating ones on my own)
– Devanshu Misra
Nov 27 '18 at 7:15
Oh, I did not know that that TLS 1.3 encrypts part of the handshake as well. Thanks for the this. Also, are there any predefined structs I can use to parse the TLS layer information? It is pretty difficult to read an RFC and follow its standards. But I'll try to do that till I find something simpler to work on(or a link that provides pre built struct to store this information without thinking and then creating ones on my own)
– Devanshu Misra
Nov 27 '18 at 7:15
Wireshark or its command line variant 'tshark' can provide protocol dissection for you so you do not have to parse raw traffic yourself. If you want a more accessible explanation of the details of TLS, have a look at this illustration: tls.ulfheim.net
– inorik
Nov 27 '18 at 19:30
Wireshark or its command line variant 'tshark' can provide protocol dissection for you so you do not have to parse raw traffic yourself. If you want a more accessible explanation of the details of TLS, have a look at this illustration: tls.ulfheim.net
– inorik
Nov 27 '18 at 19:30
add a comment |
Thanks for contributing an answer to Stack Overflow!
- 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.
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%2fstackoverflow.com%2fquestions%2f53479172%2fread-ssl-and-tls-data-in-https-traffic%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
I'm not sure what you are trying to do. The application payload (HTTP) is of course encrypted and you cannot get it. What you see in wireshark are TLS layer information, i.e. certificate, key exchange, offered ciphers, used protocol version ... . They can be extracted by parsing the TLS records according to the specification which you can find in the TLS standards.
– Steffen Ullrich
Nov 26 '18 at 12:09
"Is it possible to parse and store SSL and TLS data without decryption?" Imagine if anyone could do that, don't you think that it would break TLS guarantee on integrity and confidentiality of exchanges, and mean that everyone would be able to read anyone's web traffic, including to banks, personal accounts, health related activity, etc. hence defeating the very true core nature of TLS? Besides the few first handshake messages (with TLS 1.3 far more are encrypted), everything else (HTTP headers and content) is encrypted, using a key negotiated during handshake.
– Patrick Mevzek
Nov 26 '18 at 15:44
@SteffenUllrich Thanks for the link. I'll check it out and update you guys on the same. Also, I don't want the application payload since it hampers with the integrity and confidentiality provided by the Encrypted HTTPS communication. Thanks again for the insight.
– Devanshu Misra
Nov 27 '18 at 7:09
@PatrickMevzek I think you misunderstood my question. I wanted the TLS Layer Information as I have mentioned in the question and the screenshot posted above. Not the encrypted data. I am building a network monitoring application and not a sniffer to hack public data. I'm sorry for the misunderstanding and would try to be more precise and clear about my queries. Thank you for pointing it out.
– Devanshu Misra
Nov 27 '18 at 7:12