Viktor Dukhovni wrote:
On Sat, Dec 28, 2013 at 05:56:41PM +0100, Michael Str?der wrote:
http://vdukhovni.github.io/ietf/draft-ietf-dane-smtp-with-dane-05.html#rfc.section.1.2
This is why I am working to implement and standardize SMTP with DANE TLS.
DANE itself does not help. It just shifts
On Sat, Jan 04, 2014 at 07:58:20PM +0100, Michael Str?der wrote:
While indeed SMTP with DANE TLS relies on DNSSEC to secure the
MX lookup, it also critically relies on DANE for two additional
pieces of information:
- Downgrade resistant STARTTLS support signalling.
On Sat, Jan 4, 2014 at 2:42 PM, Viktor Dukhovni
openssl-us...@dukhovni.org wrote:
... A substantive comment that argues that DANE adds
nothing new to SMTP would begin by explaining in detail how SMTP
to MX TLS security is possible without DNS data integrity (thus
making it possible to not
On Sat, Jan 04, 2014 at 03:11:16PM -0500, Jeffrey Walton wrote:
... A substantive comment that argues that DANE adds
nothing new to SMTP would begin by explaining in detail how SMTP
to MX TLS security is possible without DNS data integrity (thus
making it possible to not trust the root
Viktor Dukhovni wrote:
With SMTP, PKIX certificate verification is pointless without explicit
per-destination configuration:
http://vdukhovni.github.io/ietf/draft-ietf-dane-smtp-with-dane-05.html#rfc.section.1.2
This is why I am working to implement and standardize SMTP with DANE TLS.
On Sat, Dec 28, 2013 at 05:56:41PM +0100, Michael Str?der wrote:
http://vdukhovni.github.io/ietf/draft-ietf-dane-smtp-with-dane-05.html#rfc.section.1.2
This is why I am working to implement and standardize SMTP with DANE TLS.
DANE itself does not help. It just shifts the trust anchor
On 12/27/2013 03:39 PM, Viktor Dukhovni wrote:
There's your problem! This server (likely Exchange 2003) has a broken
implementation of 3DES CBC padding (search Postfix users archives for
my posts on the subject), and your cipher list is either long enough
to cause it to not see RC4-SHA and
|SMTP TLS, but I am not obligated to provide a comprehensive
|justification in response to every trollish one liner, the above
Luckily there is the UDPish EDNS0 extension from RFC 2671 as in
The default is 1280 (RFC 2671, 4.5.1.).
The minimum is 1024 (RFC 3226, 3.; note: not 1220!).
The
On Sat, Dec 28, 2013 at 12:23:21PM -0600, Bobber wrote:
Thanks very much for your help Viktor. I was able to specify the
RC4-MD5 cipher and it works.
I am using Qmail with the John Simpson patch set by the way. There
is a control file (tlsclientcipher) which John had not documented
but
On 12/28/2013 12:51 PM, Viktor Dukhovni wrote:
Does this modify the ciphers used for all connections, or just for the
server in question?
All connections.
Any suggestions for what ciphers to put in the list besides RC4-MD5?
If you read my previous responses on this thread, you'll notice I
On Sat, Dec 28, 2013 at 12:58:58PM -0600, Bobber wrote:
Does this modify the ciphers used for all connections, or just for
the server in question?
All connections.
In that case I would go for the second cipherlist, though still
compact, it is a superset of the first and will interoperate
On Fri, Dec 27, 2013 at 12:59:11PM -0600, Bobber wrote:
I recently upgraded my companies' mail server to 64 Debian Wheezy. I
am using the Openssl package which is version 1.0.1e-2.
I am having problems when trying to send a message to one of our
business partners. The SMTP session appears
On 12/27/2013 01:29 PM, Viktor Dukhovni wrote:
On Fri, Dec 27, 2013 at 12:59:11PM -0600, Bobber wrote:
I recently upgraded my companies' mail server to 64 Debian Wheezy. I
am using the Openssl package which is version 1.0.1e-2.
I am having problems when trying to send a message to one of our
i am not following this in any detail, but if you look at the certificate you
included in your original email it expired in 2008. just look at it with
openssl -text -in some file
sorry if i'm jumping into something i've misunderstood,
andrew
On Fri, Dec 27, 2013 at 01:47:47PM -0600,
On 12/27/2013 01:53 PM, andrew cooke wrote:
i am not following this in any detail, but if you look at the certificate you
included in your original email it expired in 2008. just look at it with
openssl -text -in some file
Ok, that's good. Thanks.
sorry if i'm jumping into something
Hey there...
On 2013-12-27, at 2:47 PM, Bobber wrote:
On 12/27/2013 01:29 PM, Viktor Dukhovni wrote:
On Fri, Dec 27, 2013 at 12:59:11PM -0600, Bobber wrote:
I recently upgraded my companies' mail server to 64 Debian Wheezy. I
am using the Openssl package which is version 1.0.1e-2.
I
On 12/27/2013 01:54 PM, andrew cooke wrote:
On Fri, Dec 27, 2013 at 04:53:41PM -0300, Andrew Cooke wrote:
i am not following this in any detail, but if you look at the certificate you
included in your original email it expired in 2008. just look at it with
openssl -text -in some file
Bobber bob...@kc0dxf.net wrote on 12/27/2013 02:47:47 PM:
I don't see anywhere that it says expired other than this utility. How
can I verify that it is really expired?
In case you don't trust your openssl install, here is an easy approach
using windows:
1. Select everything between
On Fri, Dec 27, 2013 at 02:54:55PM -0500, Patrick Patterson wrote:
Why does no-one else notice? Probably because you've got your
server set to actually validate TLS certs, as opposed to most of
the world that doesn't. :)
With SMTP, PKIX certificate verification is pointless without explicit
On Fri, Dec 27, 2013 at 02:07:56PM -0600, Bobber wrote:
Yes, thanks Andrew, I got it. I see that it is expired. I am still a
bit baffled. I upgraded my mail server just a couple of weeks ago
from Debian Squeeze. Everything was fine before then. Is there a
different check involved in the
On 12/27/2013 02:22 PM, Viktor Dukhovni wrote:
You're posting to the wrong forum. The problem is not OpenSSL, rather
you have an updated release of your MTA. (Is it Exim or Postfix? Go to
the corresponding mailing list). OpenSSL performs whatever certificate
verification your MTA asks for.
On Fri, Dec 27, 2013 at 03:28:46PM -0600, Bobber wrote:
=== TLS started w/ cipher DES-CBC3-SHA
=== TLS peer subject DN=/C=US/ST=Missouri/L=Saint Louis/O=The
Lawrence Group/OU=IT/OU=Terms of use at www.verisign.com/rpa
(c)05/CN=mail.thelawrencegroup.com
There's your problem! This server
On 12/27/2013 03:39 PM, Viktor Dukhovni wrote:
On Fri, Dec 27, 2013 at 03:28:46PM -0600, Bobber wrote:
=== TLS started w/ cipher DES-CBC3-SHA
=== TLS peer subject DN=/C=US/ST=Missouri/L=Saint Louis/O=The
Lawrence Group/OU=IT/OU=Terms of use at www.verisign.com/rpa
On Fri, Dec 27, 2013 at 09:39:52PM +, Viktor Dukhovni wrote:
On Fri, Dec 27, 2013 at 03:28:46PM -0600, Bobber wrote:
=== TLS started w/ cipher DES-CBC3-SHA
=== TLS peer subject DN=/C=US/ST=Missouri/L=Saint Louis/O=The
Lawrence Group/OU=IT/OU=Terms of use at www.verisign.com/rpa
On Fri, Dec 27, 2013 at 04:11:40PM -0600, Bobber wrote:
TLS started w/ cipher DES-CBC3-SHA
There's your problem! This server (likely Exchange 2003) has a
broken implementation of 3DES CBC padding (search Postfix users
archives for my posts on the subject), and your cipher list is
either
25 matches
Mail list logo
