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
On Sat, Jan 4, 2014 at 2:42 PM, Viktor Dukhovni
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 zone signatu
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 signall
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.
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 interoperat
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
re
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
>
|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 m
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 RC4-
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 an
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 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
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.co
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
(c)05/CN=mail.thelawrencegrou
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 se
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. Per
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 la
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
Bobber 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 -BEGIN CERTIFICATE---
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
openssl
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.
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
Ok, that's good. Thanks.
sorry if i'm jumping into something i've misund
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
openssl x509 -text -in
> sorry if i'm jump
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
sorry if i'm jumping into something i've misunderstood,
andrew
On Fri, Dec 27, 2013 at 01:47:47PM -0600, 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 am having problems when trying to send a message to one of our
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 appe
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 to shut down and it appears
that my server is rejecting the
27 matches
Mail list logo
