Done in 1e2012b7ff4a5f12273446b281775faa5c8a1858, thanks for the nudge.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4242
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Merge RT4241 here as these are best handled together.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4393
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Resolving, this has been merged.
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4506
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
X509_REQ_to_X509 returns a newly allocated X509 structure.
If you believe that it leaks somewhere else, then please reopen this ticket
with fully self-contained code, and a trace (e.g., from valgrind) showing where
the leak happens.
Emilia
--
Ticket here: http://rt.openssl.org/Ticket/Display.ht
Merged. (Please reopen if you think we should also follow up in the other
direction.)
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4393
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/ope
While we're at this, shouldn't we then also check the length in oct2priv? (And
either reject or reduce mod n.) Afaics it accepts arbitrary BNs currently,
which means some keys can be parsed but cannot be re-encoded?
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4393
Please log in a
Yep, there is no need to clean up early here (we don't guarantee that errored
calls leave everything in a pristine unmodified state). Plus this does indeed
forget to zero the pointer. Closing. Thanks for submitting, though, and thanks
David for the review!
--
Ticket here: http://rt.openssl.org/Ti
If the other EVP ciphers universally allow this then I think we must treat this
as a bug, because people may be relying on this behaviour. There is also
sporadic documentation in lower-level APIs (AES source and des.pod) that the
buffers may overlap.
If it's inconsistent then, at the very least, w
We cleaned this up a little:
- crypto/conf/ssleay.cnf was obsolete and is gone from the master branch.
- the req app now uses 2048 bits as a default if no other defaults are given.
ssleay.txt is already gone from the master branch, and the test/ ones are used
in tests.
Cheers,
Emilia
--
Ticket
Fixed in master now, commit b1413d9bd9d823ca1ba2d6cdf4849e635231
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Resolved in ba2de73b185016e0a98e62f75b368ab6ae673919 for master (1.1.0). This
isn't really a bug so we won't be backporting to stable branches, though.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
1.1.0 now defaults to no compression: dc5744cb78da6f2bcafeeefe22c604a51b52dfc5.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
This was rejected by the team.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
1.0.1m predates Logjam. We changed DH key generation to use 2048 bits by
default in OpenSSL 1.0.1n which is the first 1.0.1 release after.
The default_bits in apps/openssl.cnf is a sample certificate request
configuration and isn't really related to Logjam. But we changed it as well as
other key g
Thanks Martin. (Re-closing the ticket.)
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Rejecting - SCSV is not a TLS extension.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
openssl-1.0.1h-cmp isn't an official OpenSSL version. You should seek help
with whoever provides this library for you.
Cheers,
Emilia
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Curves aren't negotiated with the ciphersuite, but rather via a separate
extension. Since OpenSSL 1.0.2, there are
SSL_CTX_set1_curves and SSL_CTX_set1_curves_list to configure supported curves:
https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_ecdh_auto.html
OpenSSL 1.1 also has a security
This was fixed in January: 6fa805f516f5a6ff3872f1d1014a3dc9de460b99
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
This sounds like an application problem.
1) Did you recompile your source? 0.9.7 and 1.0.1 are not binary-compatible.
2) The certificate hash format has changed between 1.0.1 and 0.9.7, which could
explain why the lookup no longer works:
https://www.openssl.org/docs/manmaster/apps/rehash.html
If t
Given OpenSSL's eternal type confusion, this check is meant to trap callers
that get an error return (typically -1) from some API returning signed values
and pass that on to PACKET_buf_init as a size_t. For example, ssl3_get_message
returns a long to signal buffer length, and that makes me nervous.
Nope, not doing anything wrong. makedepend is bust and can't find the headers.
Our clang and OS/X configurations were a bit off - I've changed them to use
clang for 'make depend' as well when clang is the compiler, see commit
c97c7f8d53dda12f4fda24fc7542281999df97f6.
Cheers,
Emilia
__
Thanks for the report. This has now been addressed in 1.0.1+, see commit
bfc19297cddd5bc2192c02c7f8896d804b0456cb.
Cheers,
Emilia
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Closing, not an OpenSSL defect.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Closing, because it's not an OpenSSL defect, but feel free to continue the
discussion on openssl-users.
Cheers,
Emilia
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
I'm afraid we can't tell from your report whether the bug is in OpenSSL or in
your application code. We need a reproducible report - for example, a
standalone code snippet, or a sample input to the openssl command-line tool.
Cheers,
Emilia
___
openssl-d
Tracking ticket - if anyone has any concerns, please voice them now.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
You're spot on, thanks for the report! The fix ended up being slightly
different, but this is now fixed in 1.0.1+.
Cheers,
Emilia
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Thanks Rob! Resolving.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Wow, thanks for the thorough report. This was so broken that I had to go for a
pretty major rewrite. Please take a look at commits
3cdd1e94b1d71f2ce3002738f9506da91fe2af45 and
b785504a10310cb2872270eb409b70971be5e76e. (Also cherry-picked to 1.0.2 and
1.0.1.)
All your test cases now pass so I'm res
In the is_sslv3 case, the header length is recomputed to be large enough.
I also note that we've recently added a sanity check to make this explicit, see
commit
29b0a15a480626544dd0c803d5de671552544de6
Sorry that we didn't acknowledge your report!
Cheers,
Emilia
Whatever it was, it's no longer reproducible.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
It's been fixed.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
CVE-2014-0224 was fixed in 1.0.1h.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Fixed now in OpenSSL 1.0.1+, thanks for the report!
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Probably same as https://rt.openssl.org/Ticket/Display.html?id=2968. We
improved this.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
As Rich said, this is according to ASN.1 DER spec. Serial numbers are integral,
and you need 17 bytes to represent this serial number in two's complement form.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-
We didn't hear back and there's not enough info to repro; closing.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Chain building is complicated, because the issuance graph is complicated: certs
get recertified, cross-signed, etc. Different clients have different trust
stores, and will build different paths.
We recently improved OpenSSL chain building to try more paths:
see https://rt.openssl.org/Ticket/Displa
How prophetic! We now require 768 and will do another bump to 1024 in the near
future, so I'm resolving this ticket.
Cheers,
Emilia
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
No evidence that it's an OpenSSL bug. You can try openssl-users@ though I'm
afraid there's not enough detail to resolve the problem there either.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
We can't help you with legal matters:
https://www.openssl.org/docs/faq.html#LEGAL1
Please note that this tracker is for bug reports.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
It's been 5 years and we never heard back with more details, so rejecting this
ticket. I suppose it could be CVE-2014-3509, though I can't tell.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
OpenSSL has SSL_SESSION_get_id since 0.9.8, so resolving this ticket just
before its 11th anniversary.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
OpenSSL attempts to load the master/default conf before diving into the
subcommand and overriding the conf with the config in -config. It'll bail when
it can't read the file, but only warn if the file does not exist.
This seems wrong, and is a regression compared to 0.9.8, so I'm going to leave
th
Hm.
You pass in a NULL key. The docs say that a NULL key indicates that we should
reuse the existing key. With a new CTX, there is nothing to reuse, so it seems
reasonable that the call should fail.
If you actually wanted to set up the context with an empty key, you'd have to
pass in a dummy key
There doesn't seem to be an open action item for OpenSSL here, so resolving
this ticket.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
The fix was committed in 995207bedcc58f2fa1bd7c460ee530b92c7dfbfe, so I think
we can resolve this ticket.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Hi Pavel,
I'm closing this ticket because there isn't sufficient detail to conclude that
it's an OpenSSL bug, and not a problem with the plugin, or your environment.
You can try asking for help on openssl-users@, though it looks more like a
question for the Miranda NG community.
Emilia
I am afraid that there is not enough information here to diagnose the problem.
We'd need to see a more detailed trace and/or the ClientHello contents.
This could be https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-0291,
which was fixed in 1.0.2b, but I can't tell.
_
Committed in fb029cebaeb6b0dbdb05a26a515e38a52a3c0fa1.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
I believe this can't happen, but addressed in
394f7b6fcc38132b8ccff0a3253b9dd15640cfc0 anyway.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Fixed in 25d6b3401ca40c9a2cbe5080449c1c2a3703.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Working as intended on the OpenSSL side. Marking resolved.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Yes, this is intentional. See also the issuer_hash_old and subject_hash_old
options in the x509 utility:
https://www.openssl.org/docs/manmaster/apps/x509.html
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-d
Resolving: seems that this was fixed in
dfba17b4f3b2f87b50f2251a608d1911bfd202bc
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Resolving - this was fixed in 1.0.1k.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Please see https://rt.openssl.org/Ticket/Display.html?id=3439
Your symptoms match, so it looks like unfortunately you were relying on an
OpenSSL bug to get the desired application behaviour.
___
openssl-dev mailing list
To unsubscribe: https://mta.opens
Everything seems to be working as intended; closing this ticket.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Fixed in 88f4c6f3d2f884715f8f5f8eb81f0a96cbec8cef, thanks for spotting!
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Error codes aren't part of the API. It's a bit of a grey area in some cases,
but for EVP_DecryptFinal_ex, you really should be checking the return value and
not relying on errors left on stack. In particular, reporting detailed
decryption errors was a historical mistake that has led to serious atta
Resolved - please see #3567 for details.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager
This is now fixed in development branches and will be addressed in the next
release. For 0.9.8, the commits are
af32df0a8e662914f78c93736466c746f83dfe84
and
9880f63038a5b9bb8bf5becc18360378cfe7806d
We received multiple reports for this issue - thank you all who reported!
Emilia
_
Applied to all branches, thanks!
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager maj
FYI,
https://rt.openssl.org/Ticket/Display.html?id=3558 may also be of interest.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Aut
Thanks for reporting!
The leak would only be meaningful if the caller is doing mac-then-encrypt and
is attempting to proceed with the mac-check in constant-time following a call
to EVP_DecryptInit_ex. It also doesn't affect TLS mac-then-encrypt because TLS
uses a different padding scheme, and a di
And thanks once again!
This has now been backported from master commit
adb46dbc6dd7347750df2468c93e8c34bcb93a4b
to all other branches. Note that I rewrote the constant-time ops in the
follow-up commit
455b65dfab0de51c9f67b3c909311770f2b3f801
If you'd like to verify that I didn't mess up the re
Thanks!
This is now in all branches in somewhat modified form (using the common
constant-time header), see commit
294d1e36c2495ff00e697c9ff622856d3114f14f
__
OpenSSL Project http://www.openssl.org
Thanks! This has now been applied to all branches.
(Original commit 2b0180c37fa6ffc48ee40caa831ca398b828e680)
__
OpenSSL Project http://www.openssl.org
Development Mailing List
Both suggested patches have been applied (with small modifications) to all
branches above and including 1.0.0. See commits
0388ac4c99e801462dafef3f2dab3f255ec33c96
and
f063e30fe9f316067950bdf0397b51cf87d4b6a6
Thanks!
__
OpenSSL P
Applied in slightly amended form to all branches, see commits
be0477a8e97a1f771f8aa6e97aa064033f4dcade
and
3aac17a82fbaf2bc23ee62f24611e5883d3e7b97
__
OpenSSL Project http://www.openssl.org
Developm
Applied to all applicable branches (1.0.0+), see commits
bc46db60f170873cc323e78e71e582adfa0ddf7f
and
e19c93811f0db499c98d2888f1c0c0ab65e6238a
__
OpenSSL Project http://www.openssl.org
Development M
This was already fixed in master and 1.0.2 by commit
7753a3a68431aa81b82beea4c3f5374b41454679. This commit has now also been
backported to all other branches.
__
OpenSSL Project http://www.openssl.o
73 matches
Mail list logo