On Tue, Mar 25, 2014 at 09:23:58PM +, geoff_l...@mcafee.com wrote:
It looks as though CVE-2014-0076 affects OpenSSL 0.9.8-based
distributions as well, correct?
Isn't this an ECDSA issue? I thought that EC algorithms are by
default disabled in OpenSSL 0.9.8 (require explicit ECCdraft in
On Tue, Mar 25, 2014 at 05:37:49PM +0100, Tomas Mraz via RT wrote:
Can OpenSSL developers please at least say what they think about the
acceptability of the SYSTEM keyword support in the cipher string? I'd
like to add the support to Fedora openssl package but we would like to
see it
On Thu, Mar 27, 2014 at 08:11:59PM +0100, Kurt Roeckx wrote:
On Thu, Mar 27, 2014 at 05:20:06PM +, Viktor Dukhovni wrote:
What would an O/S distribution do with SYSTEM that would make it
better than DEFAULT or ALL?
You really do not want to use DEFAULT. And some people even set
On Fri, Mar 28, 2014 at 05:57:42PM +0100, Dr. Stephen Henson wrote:
In the new Fedora we will try system-wide configuration parameters for
all crypto libraries (patch [0] was along that line), so such a change
is very good news. It would be nice if that branch was public for
comments or
On Fri, Mar 28, 2014 at 05:23:45PM +, Tim Hollebeek wrote:
Windows XP is no longer a supported operating system. If you
require compatibility with it, use a non-default cipher suite. It
really is time for RC4-SHA1 to go away.
That's nice, but wishing it, does not make it so. There are
On Fri, Mar 28, 2014 at 10:40:33AM -0400, Hubert Kario wrote:
Because 3DES is required to provide backwards compatibility for
old clients and received extensive cryptanalysis, it should remain
in DEFAULT cipher set.
As must RC4-SHA1. There are still considerably many Windows XP
and Windows
On Fri, Mar 28, 2014 at 06:57:34PM +0100, Dr. Stephen Henson wrote:
Well what goes in each security level is up for discussion and can be changed.
So perhaps session tickets can be allowed at somewhat higher levels?
As you note level 2 and higher general will have problems with today's
On Fri, Mar 28, 2014 at 07:27:59PM +0100, Dr. Stephen Henson wrote:
One possibility I'd considered is to move levels 1 and above along one. Then
you'd have...
Level 0: anything goes.
Level 1: almost anything goes but stupid stuff like DH, RSA keys 512 bits
excluded.
And the corresponding
On Fri, Mar 28, 2014 at 02:39:17PM -0400, Hubert Kario wrote:
As must RC4-SHA1. There are still considerably many Windows XP
and Windows 2003 systems whose strongest working cipher-suite is
RC4-SHA1, and whose 3DES cipher-suite implements broken CBC padding
(perhaps the breakage is in
On Fri, Mar 28, 2014 at 07:44:53PM +0100, Dr. Stephen Henson wrote:
What are your thoughts on level 1? Do you think those requirements are
reasonable? Currently (subject to change!) level 1 is the default level.
I am not personally aware of any interoperability obstacles to the
proposed level
On Fri, Mar 28, 2014 at 03:11:46PM -0400, Hubert Kario wrote:
I am much more concerned about servers than clients, but it is
likely that TLS client apps on XP (perhaps Outlook Express, ...)
also have similar problems.
From what I found through googling I see that the issue was actually
On Fri, Mar 28, 2014 at 08:00:06PM +0100, Dr. Stephen Henson wrote:
Therefore, implementations can over time move to encrypt session
tickets with 256-bit keys. So I would not exclude session tickets
at any of the security levels, this adds no security, but makes
the use of security less
On Sun, Mar 30, 2014 at 11:20:51AM +0200, Steffen Ullrich via RT wrote:
- wrong: according to RFC 6125 section 7.2 only the leftmost label should be
checked for wildcards, but you support also something like
www.*.example.com (there is even a test for it).
Well, wrong is perhaps too
On Fri, Mar 28, 2014 at 07:44:53PM +0100, Dr. Stephen Henson wrote:
Certainly. Nothing is set in stone at this stage. It's only part of the master
branch and wont appear in a release for a while yet.
[...]
Yes I'm aware of some of the problems here. I do want OpenSSL to reject
attempts
On Mon, Mar 31, 2014 at 02:13:22PM +0200, Nikos Mavrogiannopoulos wrote:
This looks indeed cleaner, but based on my understanding of openssl, I
think the main issues with that, is (1) that applications may not call
OPENSSL_config at all,
Perhaps to deliberately isolate themselves from
On Mon, Mar 31, 2014 at 08:49:37AM -0400, Hubert Kario wrote:
There is no benefit in excluding RC4-SHA1 from the default list.
When servers support stronger algorithms, those will be negotiated.
All you get by exclusing RC4-SHA1 is loss of interoperability, which
may be OK for dedicated
On Mon, Mar 31, 2014 at 03:39:10PM +0200, Nikos Mavrogiannopoulos wrote:
This too feels like intrusive overreach. What problem are you
trying to solve?
The goal is to allow the configuration of the security level of
applications centrally in a system. That is, to not require the
On Mon, Mar 31, 2014 at 07:36:19PM +0200, stefan.n...@t-online.de wrote:
To me, carefully starting to drop outdated/weak
ciphersuites, so early adopters can test and provide
feedback (both asking the communication partner to
upgrade their software and giving feedback on how
usable the new
On Tue, Apr 01, 2014 at 05:03:32PM -0400, Salz, Rich wrote:
I, for one, would not want OpenSSL to employ such a complex
and fragile mechanism.
Yeah, it's kinda gross and clunky. On the other hand, it's really
all we have right now, and rejecting a cert with a SAN name of
*.com is a good
On Wed, Apr 02, 2014 at 12:57:28AM +0200, Dr. Stephen Henson wrote:
I am far from sure the callback is worth the trouble.
The initial aim of X509_check_host was to support minimal host name matching
which until then wasn't in OpenSSL at all. It wasn't intended to cover every
case but to be
On Tue, Apr 01, 2014 at 07:07:10PM -0700, Howard Chu wrote:
Viktor Dukhovni wrote:
I can contribute a patch, that addresses many of the issues. Things
that I'm not immediately planning to address are:
- Separate flag for wildcards in CN vs. wildcards in SAN dnsName.
(LDAP case
On Wed, Apr 02, 2014 at 07:24:21AM -0400, Salz, Rich wrote:
I don't think it makes sense to have a separate flag.
What's the harm in looking at the CN if you don't find a match in the SAN?
Well, in fact if any DNS SANs exist, per RFC 6125 and other prior
art, one in fact must not look at the
On Wed, Apr 02, 2014 at 11:45:05AM -0400, Salz, Rich wrote:
A quick check of some of our customers shows that out of 4200
SSL certs, 820 have a wildcard CN.
Right, I think this makes particular sense for Akamai customers,
for whom you likely host multiple related web sites and coordinating
the
On Thu, Apr 03, 2014 at 02:33:17PM +0300, Costas Stasimos wrote:
[ I think this thread belongs on openss-users, not openssl-dev, setting
Reply-To: accordingly. ]
I use openssl-1.0.1e in a debian system and i try to make some scenarios
with TLSv1.2 using the applications s_server and
On Thu, Apr 10, 2014 at 12:46:23PM -0400, Salz, Rich wrote:
We've been compiling -DOPENSSL_NO_BUF_FREELISTS forever. Our
only complaint is that the BUF is misspelled :)
Apparently, this introduces a problem when free() actually wipes
freed memory, rather than just putting it on the free list.
On Thu, Apr 10, 2014 at 03:33:09PM -0400, Steven Kneizys wrote:
But from what I am reading it seems like we have
a patched version but that the problem isn't fully fixed.
The specific problem is fully fixed. The ongoing discussion is
about structural improvements to the code to make similar
On Mon, Apr 14, 2014 at 08:27:17PM +0200, Tom Swirly via RT wrote:
We'd like to make sure that the libraries we're linking to are
up-to-date. There are third parties who build our codebase who
might not be as careful
as we might like.
Postfix issues warnings whent the run-time library
On Thu, Apr 17, 2014 at 09:40:57AM +0200, Peter Malone via RT wrote:
I believe the following memcmp call is vulnerable to a remote timing
attack.
https://github.com/openssl/openssl/blob/master/ssl/ssl_lib.c#L1974
static int ssl_session_cmp(const SSL_SESSION *a,const SSL_SESSION *b)
The
On Wed, Apr 23, 2014 at 07:21:23PM -0400, Daniel Kahn Gillmor wrote:
A serious way to fix this is to have the documentation produced *from*
the code, so that it gets upgraded in sync. For example, neither
x509(1ssl) nor openssl x509 -help ever mention the -sha256 option,
but that option has
On Wed, Apr 23, 2014 at 10:23:11PM -0400, Daniel Kahn Gillmor wrote:
A serious way to fix this is to have the documentation produced *from*
the code, so that it gets upgraded in sync. For example, neither
x509(1ssl) nor openssl x509 -help ever mention the -sha256 option,
but that option
On Thu, Apr 24, 2014 at 04:56:09PM -0700, Quanah Gibson-Mount wrote:
The problem with this approach are significant requests that have languished
for years. One such example would be
http://rt.openssl.org/Ticket/Display.html?id=1365, which is 8 years old
now. The best place to get the fix
On Wed, Apr 23, 2014 at 11:09:59PM -0400, Helmut Tessarek wrote:
Every time I run openssl s_client -connect example.com:443, I get a
Verify return code: 20 (unable to get local issuer certificate).
It works, if I specify a -CAfile. The problem is I have to specify this
_every_ time I run
On Sun, Apr 27, 2014 at 02:08:12PM +0200, Kurt Roeckx via RT wrote:
But then I think think that we shouldn't have rpaths in the first
place, so I wouldn't have a problem with removing the rpath.
While rpaths are not needed in some contexts, they are important
in others, please do not remove
On Sun, Apr 27, 2014 at 01:04:13PM +0200, sch_m via RT wrote:
I was playing around with openssl and found a minor bug which
makes possible to put the end date before the start date. This
happend by creating a certificate using
I think this is a feature, not a bug. It should be possible to
On Thu, May 01, 2014 at 01:26:48PM +0200, Stephen Henson via RT wrote:
Workaround: Force protocol to SSLv3 or recompile without the define
above.
If there were an SSL_OP_ flag to allow applications to disable
padding, that would be useful for SMTP applications. There is
precious little
On Thu, May 01, 2014 at 12:08:50PM -0400, John Foley wrote:
This is a known problem in the Ironport TLS stack. Ironport has
released a hot patch to address this problem.
Any links to the fix?
I'd like to post a link to the fix to the Postfix and Exim users
lists, so that if anyone runs into
On Thu, May 01, 2014 at 01:23:51PM -0400, John Foley wrote:
I'm trying to get that information from the IronPort team. In the mean
time, this bug report appears to have some details:
https://tools.cisco.com/bugsearch/bug/CSCuo25329
Sadly, this requires a login. The bug is however
On Thu, May 01, 2014 at 12:35:52PM +0100, Rob Stradling wrote:
Steve, have you considered trimming the DEFAULT cipher list?
This would be a *major* incompatibility. The master branch has
security levels, which are a step in the right direction.
It is perhaps safe to drop EXPORT, LOW and MD5,
On Fri, May 02, 2014 at 04:12:33PM +0200, Kurt Roeckx wrote:
As I understand things, RC4 needs to be before 3DES because some
exchange servers have broken 3DES and don't support anything else.
No, that's a misreading of my posts. It suffices for RC4-SHA to
be in the 64 ciphersuites in the
On Sun, May 04, 2014 at 11:59:55PM +0100, Matt Caswell wrote:
As far as I understand if you want to have both -lssl -lcrypto you
should use openssl instead of libssl?
Anyway, I think this makes perfect sense and if things break it's
easy enough to fix it.
I'd be interested to hear
On Tue, May 06, 2014 at 02:32:05PM -0400, John Foley wrote:
The defect information is available at
https://tools.cisco.com/bugsearch/bug/CSCuo25329. This defect is
viewable to the public. You'll have to register for an account to view
the data.
After registering, the bug details are:
On Thu, May 08, 2014 at 09:48:43AM +0200, Stephan M?hlstrasser via RT wrote:
I posted this test case for function X509_check_akid() on the
openssl-users mailing list, but got no reaction, therefore I'm
submitting it now as a defect for triaging.
Test case:
1) Certificate that has an
On Tue, May 13, 2014 at 01:28:55AM +0200, Aaron Zauner wrote:
I am somewhat involved with the BetterCrypto(.org) project that tries to
provide the operations community with a BCP for daemon settings,
references and other recommendations.
Be careful what you advise, sometimes seemingly more
On Tue, May 13, 2014 at 03:02:21AM +0200, Aaron Zauner wrote:
Can you describe in words what you believe to be the nature of the
inconsistency you found? The semantics of OpenSSL cipherlist
strings definitely changed for the better in 1.0.0, were you
expecting identical results?
Yes I
On Sat, May 24, 2014 at 03:06:51PM +0200, Krzysztof Kwiatkowski via RT wrote:
Hello,
This patch implements request for ticket 2578. I've also created pull
request in github that you can find here:
https://github.com/openssl/openssl/pull/108
Thanks. Shouldn't this also support IPv6?
--
On Sun, May 25, 2014 at 09:24:32PM +0200, Michael Tuexen wrote:
On 25 May 2014, at 19:30, Kurt Roeckx k...@roeckx.be wrote:
On Sun, May 25, 2014 at 02:40:08PM +0200, Krzysztof Kwiatkowski wrote:
Hi,
In general yes, but it seems s_client (https://lwn.net/Articles/486369/)
doesn't
On Mon, May 26, 2014 at 07:24:54PM +0100, Ben Laurie wrote:
Finally, all of them have a bias: they're much more likely to pick a
prime with a long run of non-primes before it than one that hasn't (in
the case of the DH ones, the condition is slightly more subtle,
depending on parameters, but
On Mon, May 26, 2014 at 08:23:07PM +0100, Ben Laurie wrote:
Where do you see the bias?
They all work by picking a random number and then stepping upwards
from that number until a probable prime is found. Clearly, that is
more likely to find primes with a long run of non-primes before than
On Mon, May 26, 2014 at 08:20:43PM +, mancha wrote:
For our purposes, the operative question is whether the distribution
bias created can be leveraged in any way to attack factoring (RSA) or
dlog (DH).
The maximum gap between primes of size $n$ is conjectured to be
around $log(n)^2$. If
On Tue, May 27, 2014 at 09:04:20PM +0100, Ben Laurie wrote:
It inspired my son, Felix, and I to think about a related idea:
generate random numbers which are inherently coprime to small primes.
Felix went on to implement the idea, and include benchmarks and tests.
When you say small, you mean
On Thu, May 29, 2014 at 11:30:51AM +0200, user4781 . via RT wrote:
When I build openssl-1.0.1g, the shared libraries are named:
libcrypto.so.1.0.0
libssl.so.1.0.0
This is the ABI version. The numbers are intentional and correct.
--
Viktor.
On Sun, Jun 01, 2014 at 07:18:18PM +0200, Stephen Henson via RT wrote:
I've updated OpenSSL so the padding extension is no longer used by default and
the option SSL_OP_TLSEXT_PADDING enables it (it is part of the SSL_OP_ALL).
This resolves this issue as applications can now decide whether to
On Sun, Jun 01, 2014 at 07:47:30PM +0200, Dr. Stephen Henson wrote:
Thanks. In particular, since SSL_OP_ALL is a compile-time constant,
applications compiled with older releases will not send the extension
by default. Only applications compiled against 1.0.1g or later
that use
On Sun, Jun 01, 2014 at 08:32:55PM +0200, Dr. Stephen Henson wrote:
Repurposing bits in this way is problematic if that bit meant something else
in any OpenSSL-1.x.y release (notional ABI). If the bit is from 0.9.x, and
was never used in 1.x.y, then it is OK.
I think it is actually a
The new prime generator does not ensure that generated primes are
safe modulo 2, 3, 5, 7 or 11. In particular (p-1)/2 might not
be co-prime to 2310.
The patch below my signature addresses this problem.
--
Viktor.
diff --git a/crypto/bn/bn_prime.c b/crypto/bn/bn_prime.c
index
On Sun, Jun 01, 2014 at 08:14:00PM +, Viktor Dukhovni wrote:
The new prime generator does not ensure that generated primes are
safe modulo 2, 3, 5, 7 or 11. In particular (p-1)/2 might not
be co-prime to 2310.
The patch below my signature addresses this problem.
Oops, previous patch
On Sun, Jun 01, 2014 at 09:45:15PM +0100, Ben Laurie wrote:
You didn't update the test...
You're right. The below should take care of that.
--
Viktor.
diff --git a/crypto/bn/bn_prime.c b/crypto/bn/bn_prime.c
index 2d66b61..df50305 100644
--- a/crypto/bn/bn_prime.c
+++
On Sun, Jun 01, 2014 at 11:12:53PM +0200, Kurt Roeckx wrote:
On Sun, Jun 01, 2014 at 09:04:29PM +, Viktor Dukhovni wrote:
@@ -1,21 +1,37 @@
-primes = [2, 3, 5, 7, 11]
-safe = False # Not sure if the period's right on safe primes.
+# Odd primes 13
+#
+primes = [3, 5, 7, 11, 13
On Sun, Jun 01, 2014 at 10:55:09PM +0200, Dr. Stephen Henson wrote:
Well that's one of the issues we need to resolve. Apache now compiles with
OPENSSL_NO_SSL_INTERN but it needed some additional accessor functions before
it could.
FWIW, Postfix TLS support predates OpenSSL 0.9.7, but the only
On Tue, Jun 03, 2014 at 04:59:58AM +0200, Lubo Diakov via RT wrote:
Please review the proposed patch for /openssl-1.0.1g/crypto/opensslv.h
meant to correct a typo in the SHLIB_VERSION_NUMBER at the end of this
message.
Recently I compiled OpenSSL 1.0.1g and found that it numbers the
On Tue, Jun 03, 2014 at 06:01:03PM +0200, Tomas Mraz via RT wrote:
openssl advertises ECC ciphersuites in SSLv2 client hello if ssl23
method is used. This is incorrect because the TLS extensions that
indicate supported curves and point formats cannot be sent in SSLv2
client hello. The
On Wed, Jun 04, 2014 at 10:45:59AM +0200, Tomas Mraz wrote:
SSLv2 is disabled by default, however when you use the ALL cipher list
which is of course something you should not do but it happened in perl
LDAP module the SSLv2 ciphers are added to the cipherlist and SSLv2
client hello is used.
On Fri, Jun 06, 2014 at 09:15:02AM +0200, Kurt Roeckx wrote:
I ended up using the cflags in Configure for that.
I wrote a script that takes the output of Configure TABLE to
extract the settings for my desired target, makes appropriate
additions to the desired field, and then runs Configure with
On Fri, Jun 06, 2014 at 10:42:06AM -0400, Salz, Rich wrote:
Perhaps Configure should have a -f nnn flag, that lets folks
add their own local table without having to patch the script
I think this misses the point, one can already just pass a table
entry on the command-line as a colon-separated
On Mon, Jun 09, 2014 at 11:14:54AM -0700, Quanah Gibson-Mount wrote:
It could be fixed for 1.0.2 however, right? It's reasonable to expect the
API to change across major releases.
The 1.0.2 release is NOT a major release. The ABI is supposed to
be stable across both patch and micro releases.
On Tue, Jun 10, 2014 at 02:33:00PM +0200, Hubert Kario via RT wrote:
Note that I've included also few other simple changes already present in
master that are applicable to either the 1.0.1 or 1.0.2 code base.
The differences between master and 1.0.x which I taken into account while
On Tue, Jun 10, 2014 at 12:10:23PM -0400, Hubert Kario wrote:
* aRSA, kRSA and RSA groups behave differently in master and 1.0.x
Which differences did you have in mind specificically for the above?
On second look, there is no difference in behaviour between 1.0.2 and master.
I
On Tue, Jun 10, 2014 at 09:02:18PM +0200, Matt Caswell via RT wrote:
Steve Henson says:
Looks like the SRP cipher decriptions are broken and we need an SSL_aSRP to
do
the same as SSL_aPSK.
Also looks like he already fixed the issue in 1.0.0 and later.
Which is all the branches that have
When I compile Postfix against OpenSSL 1.0.2-beta or earlier, and
configure the SMTP server to not have any certificates, the Postfix
client and server happily negotiate a suitable aNULL ciphersuite
(e.g. AECDH-AES256-SHA).
When I compile against master, with the same configuration, I get
on the
On Thu, Jun 12, 2014 at 08:59:27PM +0200, Dr. Stephen Henson wrote:
When I compile against master, with the same configuration, I get
on the server:
SSL3 alert write:fatal:handshake failure
SSL_accept:error in SSLv3 read client hello C
error:1408A0C1:SSL
On Thu, Jun 12, 2014 at 11:49:39AM +0200, Dimitrios Apostolou wrote:
The options start out clear by default.
Are you positive on that? I'm quite sure that SSL_OP_LEGACY_SERVER_CONNECT
is on for example.
I was not sure, looking at the code for SSL_CTX_new() in the master
development branch I
On Fri, Jun 13, 2014 at 03:53:07AM +, Viktor Dukhovni wrote:
For now, don't clear SSL_OP_NO_TICKET if
it is already set unless you've provided your own session tickets.
That is your own session ticket keys.
--
Viktor
On Sat, Jun 14, 2014 at 04:23:13PM +0200, Kurt Roeckx via RT wrote:
Yes. As far as I can see all reports are about 0.9.8o sending
large amounts of data to 1.0.1e.
So I can reproduce it. But I can only seem to be reproducing it
when using postgres having a 1.0.1 talk to a 0.9.8. For me
On Sat, Jun 14, 2014 at 07:12:06PM +0200, Kurt Roeckx via RT wrote:
So it's 0.9.8o (+patches) (server, sending data) talking to
OpenSSL_1_0_1-stable (client). After some data transfer I see:
s-c: Hello Request
c-s: Client Hello
s-c: Server Hello, Certificate, Server Hello Done
c-s: Client
diff --git a/doc/apps/s_server.pod b/doc/apps/s_server.pod
index ad8dcda..c05a6c6 100644
--- a/doc/apps/s_server.pod
+++ b/doc/apps/s_server.pod
@@ -55,6 +55,7 @@ Bopenssl Bs_server
[B-engine id]
[B-tlsextdebug]
[B-no_ticket]
+[B-no_cache]
[B-id_prefix arg]
[B-rand file(s)]
[B-serverinfo
On Mon, Jun 16, 2014 at 02:10:14AM -0400, Mike Frysinger wrote:
On Mon 28 Apr 2014 09:32:40 Salz, Rich wrote:
While rpaths are not needed in some contexts, they are important in
others, please do not remove rpath support.
Yes, such as cross-compiling or embedded systems. I think it's
On Tue, Jun 24, 2014 at 02:29:10PM +, Stefan Runkel wrote:
Stephen Henson via RT rt at openssl.org writes:
I've updated OpenSSL so the padding extension is no longer used by default
Stephen,
Does not work for me. Running sendmail 8.14.8, got the decode error
problem with openssl
On Thu, Jul 03, 2014 at 07:04:09AM -0400, Salz, Rich wrote:
Looks to me like you've only fixed this (and many others) in master - surely
should also go to 1.0.2 at least (and probably older branches, too)?
Okay, tell me which branches.
Also, we generally rebase rather than merge...
On Sat, Jul 05, 2014 at 12:17:13AM +0200, Kurt Roeckx wrote:
On Fri, Jul 04, 2014 at 10:50:47PM +0200, noloa...@gmail.com via RT wrote:
Updated text for the patch based on Viktor's reply to JW and JB on the list.
The updated text includes the a statement that its not possible to
On Fri, Jul 04, 2014 at 08:33:36PM +0200, Petr Spacek via RT wrote:
I tried to fully describe purpose and implementation directly in the code
comments.
This is no substitute for documentation. This patchset introduces
new libcrypto API elements, which need to be documented.
Please squash
On Tue, Jul 08, 2014 at 08:03:39AM +0200, Neitrino Photonov via RT wrote:
if haven't method destroy memory for a is never free.
diff --git a/crypto/bio/bio_lib.c b/crypto/bio/bio_lib.c
index 9c9646a..d6950ad 100644
--- a/crypto/bio/bio_lib.c
+++ b/crypto/bio/bio_lib.c
@@ -132,8 +132,8 @@ int
On Wed, Jul 16, 2014 at 05:46:42PM +0200, Daniel Kahn Gillmor via RT wrote:
From experimentation, i just discovered that
-days is also happy to accept and interpret negative integer arguments
as well, resulting in a key with ValidNotBefore later than ValidNotAfter
That's a useful feature, at
On Wed, Jul 16, 2014 at 10:56:03PM -0400, Salz, Rich wrote:
I have a branch that adds pretty comprehensive option-checking to all the
openssl commands:
; ./openssl x509 --CA /no/such/file
x509: Cannot open input file /no/such/file, No such file or directory
x509: Use -help
On Thu, Jul 17, 2014 at 12:09:29AM -0400, Salz, Rich wrote:
You've declared -days to take only positive numbers, it should allow
negative numbers.
Pushed, thanks.
Also the keyform option definition string looks wrong:
keyform, OPT_KEYFORM, 'f', Private key file format (PEM or ENGINE)
On Thu, Jul 17, 2014 at 12:56:40AM -0400, Daniel Kahn Gillmor wrote:
You've declared -days to take only positive numbers, it should
allow negative numbers.
why? Or at least: why accept these generally unacceptable options by
default? I can understand wanting to be able to create
On Thu, Jul 17, 2014 at 05:06:07AM +, Viktor Dukhovni wrote:
Higher-level tools can check the days argument before invoking
the openssl apps layer. It should not be necessary to write C code
to generate well-formed if corner-case certificates.
Also there is far more risk in generating
On Tue, Jul 15, 2014 at 07:31:36PM +0200, Johnson, Wayne via RT wrote:
c89 -DMONOLITH -I.. -I../include -Ww -D__TANDEM -D_XOPEN_SOURCE
-D_XOPEN_SOURCE_EXTENDED=1 -D_TANDEM_SOURCE -DB_ENDIAN -c -o ca.o ca.c
#include sys/file.h
^
On Tue, Jul 22, 2014 at 09:37:13AM -0400, Massimiliano Pala wrote:
working on porting my libpki implementation (based on OpenSSL) to MacOS I
found out an issue that is not really related to the code itself but the
distributed version in the SDK.
Apple ships OpenSSL 0.9.8.
In particular, I
On Thu, Aug 07, 2014 at 07:33:55PM +0200, Daniel Stenberg via RT wrote:
Hi
As OpenSSL is a library, it should only ever use exit in the case of sever
problems and not just for mere run-time problems.
OPENSSL_config() is documented to be strongly recommended but yet it calls
exit(1) if
[ Redirecting to openssl-users ]
On Wed, Aug 13, 2014 at 01:05:24AM +0400, Fedor Indutny wrote:
I just discovered that there is no way to force OpenSSL SSL client to send
Certificate record if server hasn't sent CertificateRequest.
That would be a TLS protocol violation.
Would a patch that
On Tue, Aug 12, 2014 at 11:17:36PM -0400, Jeffrey Altman wrote:
The modern way to combine Kerberos with TLS is GSSAPI with channel
binding. The old crufty Kerberos support should be deleted from
master. No new features should be added to this code.
RFC 2712 is a Proposed Standard. I
On Wed, Aug 13, 2014 at 03:32:00PM -0400, Salz, Rich wrote:
What's the programming model for using session cache with a multi-threaded
server?
When a client connects, a refcount on the object is incremented.
A lot depends on whether the cache is internal, or external via callbacks,
and
On Sat, Aug 16, 2014 at 07:45:43AM +0100, Dominyk Tiller wrote:
I'm pretty sure I read somewhere in the OpenSSL documentation that the
recommended default level for compile is level 1, which kills the ssl2
option, but effectively Homebrew has been building with level 0
default thus far.
On Tue, Aug 26, 2014 at 10:12:06AM -0400, Salz, Rich wrote:
Find a C version (which I have written) of the utility at:
http://git.alpinelinux.org/cgit/aports/plain/main/openssl/c_rehash.c
That's pretty cool. We'd need to modify it to not use the XXXat
functions or fnmatch, but definitely
On Tue, Aug 26, 2014 at 08:25:15PM +0300, Timo Teras wrote:
The algorithm should be improved to never delete links which are
subsequently recreated.
I almost answered it's fixed. But it's not. IIRC, the version had it
fixed, but it did not handle hash collisions nicely. This certainly is
On Fri, Aug 29, 2014 at 04:19:43PM +0200, Frank Meier wrote:
While testing different ciphersuites I found a quite drastic change in the
behavior between openssl version 1.0.1h to 1.0.1i. While using a cipherlist
like ECDHE-RSA-AES128-SHA256:RC4 with 1.0.1h the ECDHE-RSA-AES128-SHA256
cipher
On Mon, Sep 01, 2014 at 09:40:55AM -0400, Salz, Rich wrote:
What about usoing stunnel?
Stunnel's STARTTLS support does not include LDAP as the initial
protocol.
--
Viktor.
__
OpenSSL Project
On Mon, Sep 01, 2014 at 10:02:16AM -0400, Salz, Rich wrote:
My point is that since stunnel has a different goal of wrapping
almost any protocol, that might be a better place for it, rather
than going down the slippery slope of putting a binary hack into
s_client which wouldn't let you
On Mon, Sep 08, 2014 at 11:41:42PM -0600, The Doctor wrote:
ls: error initializing month strings
The literal string month does not appear in OpenSSL 1.0.2 source
code. You're probably compiling in a locale not supported by your
system. ls -l is unable to format the date.
--
Viktor.
On Thu, Sep 25, 2014 at 09:56:30PM -0500, Salz, Rich wrote:
+static int tohex(char c)
+ {
+ switch (c)
+ {
+ case '0': return 0;
+ case '1': return 1;
+ case '2': return 2;
+ case '3': return 3;
+ case '4':
1 - 100 of 450 matches
Mail list logo
