Tag:
Branch:
Tree:
cf506f17d0
2214
2272
2311
2357
2490
2564
2623
2661
2704
2785
2883
2924
2987
3029
3071
3112
3202
3239
3282
3359
3538
3945
chromium-2214
chromium-2272
chromium-2311
chromium-2357
chromium-2490
chromium-2564
chromium-2623
chromium-2661
chromium-2704
chromium-2883
chromium-2924
chromium-2987
chromium-3029
chromium-3071
chromium-3112
chromium-3202
chromium-3239
chromium-3282
chromium-3359
chromium-3538
chromium-3945
chromium-5359
chromium-5414
chromium-stable
chromium-stable-with-bazel
esni
fips-20180730
fips-20220613
fips-20230428
fips-20240407
fips-20240805
fips-20250107
fips-android-20191008
grpc-202302
infra/config
main
main-with-bazel
master
master-with-bazel
0.20240913.0
0.20240930.0
0.20241024.0
0.20241203.0
0.20241209.0
0.20250114.0
0.20250212.0
fips-20170615
fips-20180730
fips-20190808
fips-20210429
fips-20220613
fips-android-20191020
version_for_cocoapods_1.0
version_for_cocoapods_10.0
version_for_cocoapods_2.0
version_for_cocoapods_3.0
version_for_cocoapods_4.0
version_for_cocoapods_5.0
version_for_cocoapods_6.0
version_for_cocoapods_7.0
version_for_cocoapods_8.0
version_for_cocoapods_9.0
${ noResults }
2 Commits (cf506f17d0fe51a43abcc37aecb63601b70218ef)
Author | SHA1 | Message | Date |
---|---|---|---|
|
ddecaabdc8 |
Check hs->early_session, not ssl->session, for the early data limit.
ServerHello/EncryptedExtensions/Finished is logically one atomic flight that exits the early data state, we have process each message sequentially. Until we've processed Finished, we are still in the early data state and must support writing data. Individual messages *are* processed atomically, so the interesting points are before ServerHello (already tested), after ServerHello, and after EncryptedExtensions. The TLS 1.3 handshake internally clears ssl->session when processing ServerHello, so getting the early data information from ssl->session does not work. Instead, use hs->early_session, which is what other codepaths use. I've tested this with runner rather than ssl_test, so we can test both post-SH and post-EE states. ssl_test would be more self-contained, since we can directly control the API calls, but it cannot test the post-EE state. To reduce record overhead, our production implementation packs EE and Finished into the same record, which means the handshake will process the two atomically. Instead, I've tested this in runner, with a flag to partially drive the handshake before reading early data. I've also tweaked the logic to hopefully be a little clearer. Bug: chromium:1208784 Change-Id: Ia4901042419c5324054f97743bd1aac59ebf8f24 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47485 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com> |
4 years ago |
|
fb0c05cac2 |
acvp: add CMAC-AES support.
Change by Dan Janni. Change-Id: I3f059e7b1a822c6f97128ca92a693499a3f7fa8f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41984 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com> |
5 years ago |