Does TLS 1.2 have cipher suite specific algorithms/behavior for VerifyData?
I am working on a Golang implementation of DTLS, and I am not able to generate a valid value for VerifyData. I have a working example here this shows my code (and how I get something different then OpenSSL)
printf debugging OpenSSL it looks like the hash of handshake bodies is different then mine. It seems really unlikely, I would assume that I am collecting packets wrong. But putting printf statements before the
The cipher suite is TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
and you can see the entire codebase at https://github.com/pions/dtls
ssl openssl
migrated from security.stackexchange.com Nov 13 '18 at 3:45
This question came from our site for information security professionals.
add a comment |
I am working on a Golang implementation of DTLS, and I am not able to generate a valid value for VerifyData. I have a working example here this shows my code (and how I get something different then OpenSSL)
printf debugging OpenSSL it looks like the hash of handshake bodies is different then mine. It seems really unlikely, I would assume that I am collecting packets wrong. But putting printf statements before the
The cipher suite is TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
and you can see the entire codebase at https://github.com/pions/dtls
ssl openssl
migrated from security.stackexchange.com Nov 13 '18 at 3:45
This question came from our site for information security professionals.
add a comment |
I am working on a Golang implementation of DTLS, and I am not able to generate a valid value for VerifyData. I have a working example here this shows my code (and how I get something different then OpenSSL)
printf debugging OpenSSL it looks like the hash of handshake bodies is different then mine. It seems really unlikely, I would assume that I am collecting packets wrong. But putting printf statements before the
The cipher suite is TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
and you can see the entire codebase at https://github.com/pions/dtls
ssl openssl
I am working on a Golang implementation of DTLS, and I am not able to generate a valid value for VerifyData. I have a working example here this shows my code (and how I get something different then OpenSSL)
printf debugging OpenSSL it looks like the hash of handshake bodies is different then mine. It seems really unlikely, I would assume that I am collecting packets wrong. But putting printf statements before the
The cipher suite is TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
and you can see the entire codebase at https://github.com/pions/dtls
ssl openssl
ssl openssl
asked Nov 12 '18 at 9:31
Sean DuBoisSean DuBois
1048
1048
migrated from security.stackexchange.com Nov 13 '18 at 3:45
This question came from our site for information security professionals.
migrated from security.stackexchange.com Nov 13 '18 at 3:45
This question came from our site for information security professionals.
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
VerifyData (in Finished) always uses the TLS-defined PRF, which for TLS1.2 (and DTLS1.2) is a doubled HMAC using a hash which can depend on the ciphersuite. For all pre-existing ciphersuites the D/TLS1.2 PRF uses SHA256, and the new-in-TLS1.2 suite you identified also uses SHA256. (In fact it uses SHA256 only for the PRF, because GCM suites don't use HMAC on data.) Some other new-in-TLS1.2 suites use SHA384. Also the length of VerifyData in 1.2 is formally dependent on the ciphersuite, but all pre-1.2 suites must use the pre-1.2 protocol size of 12, and all new-in-1.2 suites also do use 12, so in practice there is no difference.
However, going by your gist your problem is that you included the initial ClientHello and HelloVerifyRequest, which you shouldn't. See the antepenultimate (second to last, a word I don't get to use very often!) paragraph of section 4.2.1, near the top of page 18 in rfc6347 and section 4.2.6 which also notes, although this isn't an issue in your example, that if fragmentation is used for transmission you must still hash the unfragmented messages.
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%2f53273484%2fdoes-tls-1-2-have-cipher-suite-specific-algorithms-behavior-for-verifydata%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
VerifyData (in Finished) always uses the TLS-defined PRF, which for TLS1.2 (and DTLS1.2) is a doubled HMAC using a hash which can depend on the ciphersuite. For all pre-existing ciphersuites the D/TLS1.2 PRF uses SHA256, and the new-in-TLS1.2 suite you identified also uses SHA256. (In fact it uses SHA256 only for the PRF, because GCM suites don't use HMAC on data.) Some other new-in-TLS1.2 suites use SHA384. Also the length of VerifyData in 1.2 is formally dependent on the ciphersuite, but all pre-1.2 suites must use the pre-1.2 protocol size of 12, and all new-in-1.2 suites also do use 12, so in practice there is no difference.
However, going by your gist your problem is that you included the initial ClientHello and HelloVerifyRequest, which you shouldn't. See the antepenultimate (second to last, a word I don't get to use very often!) paragraph of section 4.2.1, near the top of page 18 in rfc6347 and section 4.2.6 which also notes, although this isn't an issue in your example, that if fragmentation is used for transmission you must still hash the unfragmented messages.
add a comment |
VerifyData (in Finished) always uses the TLS-defined PRF, which for TLS1.2 (and DTLS1.2) is a doubled HMAC using a hash which can depend on the ciphersuite. For all pre-existing ciphersuites the D/TLS1.2 PRF uses SHA256, and the new-in-TLS1.2 suite you identified also uses SHA256. (In fact it uses SHA256 only for the PRF, because GCM suites don't use HMAC on data.) Some other new-in-TLS1.2 suites use SHA384. Also the length of VerifyData in 1.2 is formally dependent on the ciphersuite, but all pre-1.2 suites must use the pre-1.2 protocol size of 12, and all new-in-1.2 suites also do use 12, so in practice there is no difference.
However, going by your gist your problem is that you included the initial ClientHello and HelloVerifyRequest, which you shouldn't. See the antepenultimate (second to last, a word I don't get to use very often!) paragraph of section 4.2.1, near the top of page 18 in rfc6347 and section 4.2.6 which also notes, although this isn't an issue in your example, that if fragmentation is used for transmission you must still hash the unfragmented messages.
add a comment |
VerifyData (in Finished) always uses the TLS-defined PRF, which for TLS1.2 (and DTLS1.2) is a doubled HMAC using a hash which can depend on the ciphersuite. For all pre-existing ciphersuites the D/TLS1.2 PRF uses SHA256, and the new-in-TLS1.2 suite you identified also uses SHA256. (In fact it uses SHA256 only for the PRF, because GCM suites don't use HMAC on data.) Some other new-in-TLS1.2 suites use SHA384. Also the length of VerifyData in 1.2 is formally dependent on the ciphersuite, but all pre-1.2 suites must use the pre-1.2 protocol size of 12, and all new-in-1.2 suites also do use 12, so in practice there is no difference.
However, going by your gist your problem is that you included the initial ClientHello and HelloVerifyRequest, which you shouldn't. See the antepenultimate (second to last, a word I don't get to use very often!) paragraph of section 4.2.1, near the top of page 18 in rfc6347 and section 4.2.6 which also notes, although this isn't an issue in your example, that if fragmentation is used for transmission you must still hash the unfragmented messages.
VerifyData (in Finished) always uses the TLS-defined PRF, which for TLS1.2 (and DTLS1.2) is a doubled HMAC using a hash which can depend on the ciphersuite. For all pre-existing ciphersuites the D/TLS1.2 PRF uses SHA256, and the new-in-TLS1.2 suite you identified also uses SHA256. (In fact it uses SHA256 only for the PRF, because GCM suites don't use HMAC on data.) Some other new-in-TLS1.2 suites use SHA384. Also the length of VerifyData in 1.2 is formally dependent on the ciphersuite, but all pre-1.2 suites must use the pre-1.2 protocol size of 12, and all new-in-1.2 suites also do use 12, so in practice there is no difference.
However, going by your gist your problem is that you included the initial ClientHello and HelloVerifyRequest, which you shouldn't. See the antepenultimate (second to last, a word I don't get to use very often!) paragraph of section 4.2.1, near the top of page 18 in rfc6347 and section 4.2.6 which also notes, although this isn't an issue in your example, that if fragmentation is used for transmission you must still hash the unfragmented messages.
edited Nov 13 '18 at 9:27
answered Nov 13 '18 at 9:09
dave_thompson_085dave_thompson_085
13.2k11632
13.2k11632
add a comment |
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%2f53273484%2fdoes-tls-1-2-have-cipher-suite-specific-algorithms-behavior-for-verifydata%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