Re: sendmail broken by libssl in current

2015-03-11 Thread Xin Li 


On 3/10/15 23:57, Julian Elischer wrote:
> [sorry for reposting but the original copy I got back had been truncated]
> 
> libssl has a new "feature"
> implemented by:
> crypto/openssl/ssl/t1_lib.c
> 
> 672 /* Add padding to workaround bugs in F5 terminators.
> 673  * See https://tools.ietf.org/html/draft-agl-tls-padding-03
> 674  *
> 675  * NB: because this code works out the length of all
> existing
> 676  * extensions it MUST always appear last.
> 677  */
> 678 //if (s->options & SSL_OP_TLSEXT_PADDING)
> 
> unfortunatly this makes sendmail incompatible with various email servers
> around the world,
> including (apparently (ironically (*))) Ironport email gateways.
> It fails in TLS handshake.

I hate workarounds of workarounds :(

How about this?

%%%
Index: contrib/sendmail/src/readcf.c
===
--- contrib/sendmail/src/readcf.c   (revision 279857)
+++ contrib/sendmail/src/readcf.c   (working copy)
@@ -116,7 +116,7 @@ readcf(cfname, safe, e)

 #if STARTTLS
Srv_SSL_Options = SSL_OP_ALL;
-   Clt_SSL_Options = SSL_OP_ALL
+   Clt_SSL_Options = SSL_OP_ALL & ~SSL_OP_TLSEXT_PADDING
 #ifdef SSL_OP_NO_SSLv2
| SSL_OP_NO_SSLv2
 #endif
%%%

Cheers,
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: sendmail broken by libssl in current

2015-03-11 Thread Julian Elischer 

On 3/11/15 12:14 AM, Xin Li wrote:


On 3/10/15 23:57, Julian Elischer wrote:

[sorry for reposting but the original copy I got back had been truncated]

libssl has a new "feature"
implemented by:
crypto/openssl/ssl/t1_lib.c

 672 /* Add padding to workaround bugs in F5 terminators.
 673  * See https://tools.ietf.org/html/draft-agl-tls-padding-03
 674  *
 675  * NB: because this code works out the length of all
existing
 676  * extensions it MUST always appear last.
 677  */
 678 //if (s->options & SSL_OP_TLSEXT_PADDING)

unfortunatly this makes sendmail incompatible with various email servers
around the world,
including (apparently (ironically (*))) Ironport email gateways.
It fails in TLS handshake.

I hate workarounds of workarounds :(

How about this?

%%%
Index: contrib/sendmail/src/readcf.c
===
--- contrib/sendmail/src/readcf.c   (revision 279857)
+++ contrib/sendmail/src/readcf.c   (working copy)
@@ -116,7 +116,7 @@ readcf(cfname, safe, e)

  #if STARTTLS
 Srv_SSL_Options = SSL_OP_ALL;
-   Clt_SSL_Options = SSL_OP_ALL
+   Clt_SSL_Options = SSL_OP_ALL & ~SSL_OP_TLSEXT_PADDING
  #ifdef SSL_OP_NO_SSLv2
 | SSL_OP_NO_SSLv2
  #endif
%%%


that's certainly better.. MY change was to just prove where the 
problem was after reading a bit on the web.

The trouble is that that may break mail servers behind F5 appliances.
One wonders if one could only turn it off for every second attempt on 
a retry after a failed attempt.

or some other way of not breaking  the F5 appliances...

I found I could not talk to my child's school (department of 
education) and my bank, over a period of just a week..
I will look to see if I start picking up new failures now (and see how 
many F5 appliances there are :-).




Cheers,



___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: DRAM Rowhammer exploits

2015-03-11 Thread Julian Elischer 

On 3/9/15 12:49 PM, Dmitry Morozovsky wrote:

Dear colleagues,

any thoughts we're vulnerable to this?

http://googleprojectzero.blogspot.ch/2015/03/exploiting-dram-rowhammer-bug-to-gain.html


one important part of this exploit is the following part:
---quote---
How can we pick pairs of addresses that satisfy the “different row, 
same bank” requirements?


One possibility is to use knowledge of how the CPU’s memory controller 
maps physical addresses to DRAM’s row, column and bank numbers, along 
with knowledge of either:


 * The absolute physical addresses of memory we have access to. Linux
   allows this via /proc//PID//pagemap.
 * The relative physical addresses of memory we have access to. Linux
   can allow this via its support for “huge pages”, which cover 2MB
   of contiguous physical address space per page. Whereas a normal 4k
   page is smaller than a typical DRAM row, a 2MB page will typically
   cover multiple rows, some of which will be in the same bank.

---end quote---
I don't know of a similar source of that information in FreeBSD, 
though near the start of operation one might be able to make a good 
guess about memory allocation, until ram got too scrambled..



the "superpages" point would be true in freeBSD as well, tough I 'm 
not sure how you;d know you had a superpage, but you might be able to 
do something (file size?) that might make it likely.
Of course in their first attack it's the location of the data but the 
location of the page table entry that's important.
that might be more easily worked out if you allocated a large enough 
chunk of memory while memory is still predictable.



___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: sendmail broken by libssl in current

2015-03-11 Thread Willem Jan Withagen 

On 11-3-2015 08:58, Julian Elischer wrote:


I found I could not talk to my child's school (department of education)
and my bank, over a period of just a week..
I will look to see if I start picking up new failures now (and see how
many F5 appliances there are :-).


If you'd like to have a bit of incite on that, you could use Shodan:

https://www.shodan.io/search?query=F5
And just add futher descriptions to single out what defines a F5 appliance

Warning: it is a dangerously fascinating search-engine.

--WjW



___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

sendmail broken by libssl in current

2015-03-11 Thread Julian Elischer 

libssl has a new "feature"
implemented by:
crypto/openssl/ssl/t1_lib.c

672 /* Add padding to workaround bugs in F5 terminators.
673  * See 
https://tools.ietf.org/html/draft-agl-tls-padding-03

674  *
675  * NB: because this code works out the length of all 
existing

676  * extensions it MUST always appear last.
677  */
678 //if (s->options & SSL_OP_TLSEXT_PADDING)

unfortunatly this makes sendmail incompatible with various email 
servers around the world,

including (apparently (ironically (*))) Ironport email gateways.
It fails in TLS handshake.
These are commonly installed at companies and government departments.
consequently if you are mailing an important documant to your bank, or 
maybe some tax information to
your friendly tax department, youe emails sit in your queue for a week 
until they time out and get dropped.

(you may r may not get notified depending on your spam filters)

I had to make the following "fix" to libssl to get sendmail to be able 
to get my tax forms out.


Index: crypto/openssl/ssl/t1_lib.c
===
--- crypto/openssl/ssl/t1_lib.c(revision 279747)
+++ crypto/openssl/ssl/t1_lib.c(working copy)
@@ -675,7 +675,8 @@
  * NB: because this code works out the length of all existing
  * extensions it MUST always appear last.
  */
-if (s->options & SSL_OP_TLSEXT_PADDING)
+//if (s->options & SSL_OP_TLSEXT_PADDING)
+if (0)
 {
 int hlen = ret - (unsigned char *)s->init_buf->data;
 /* The code in s23_clnt.c to build ClientHello messages




I saw some hints that there is a change in send mail somewhere that gets
around this but haven't been able to find the exact configuration 
change required

to make it happen.

Julian

(*) Ironically because :
1/ Ironport runs on FreeBSD
2/ I used to work there.


___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: sendmail broken by libssl in current

2015-03-11 Thread Philip Guenther 
[Forwarded from Greg, before he had to go offline]


On Tue, 10 Mar 2015, Julian Elischer wrote:
> libssl has a new "feature"
> implemented by:
> crypto/openssl/ssl/t1_lib.c
> 
> 672 /* Add padding to workaround bugs in F5 terminators.
> 673  * See https://tools.ietf.org/html/draft-agl-tls-padding-03
> 674  *
> 675  * NB: because this code works out the length of all existing
> 676  * extensions it MUST always appear last.
> 677  */
> 678 //if (s->options & SSL_OP_TLSEXT_PADDING)
> 
> unfortunatly this makes sendmail incompatible with various email servers 
> around the world, including (apparently (ironically (*))) Ironport email 
> gateways. It fails in TLS handshake.
...
> I had to make the following "fix" to libssl to get sendmail to be able 
> to get my tax forms out.

This wonderful change (cough) to include SSL_OP_TLSEXT_PADDING in 
SSL_OP_ALL was addressed in sendmail 8.15.1, which explicitly removes 
SSL_OP_TLSEXT_PADDING from the default ClientSSLOptions value if that 
#define exists.  I believe Greg is working on importing that to FreeBSD.

Pending that, simply copy the relevant code from the 8.15.1's 
readcf.c:readcf(), which has this:

#if STARTTLS
Srv_SSL_Options = SSL_OP_ALL;
Clt_SSL_Options = SSL_OP_ALL
# ifdef SSL_OP_NO_SSLv2
| SSL_OP_NO_SSLv2
# endif
# ifdef SSL_OP_NO_TICKET
| SSL_OP_NO_TICKET
# endif
;
# ifdef SSL_OP_TLSEXT_PADDING
/* SSL_OP_TLSEXT_PADDING breaks compatibility with some sites */
Srv_SSL_Options &= ~SSL_OP_TLSEXT_PADDING;
Clt_SSL_Options &= ~SSL_OP_TLSEXT_PADDING;
# endif /* SSL_OP_TLSEXT_PADDING */
#endif /* STARTTLS */


You'll just need to add the #ifdef SSL_OP_TLSEXT_PADDING block.


If the default is overriden by explicitly setting the ClientSSLOptions 
option in then config, then you may need to explicitly remove it there as 
well, such as seen in the implicit default:

O ClientSSLOptions=SSL_OP_ALL SSL_OP_NO_SSLv2 SSL_OP_NO_TICKET 
-SSL_OP_TLSEXT_PADDING

This option and default is documented in op.me in the source distribution.



Philip Guenther
Proofpoint Engineering
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: sendmail broken by libssl in current

2015-03-11 Thread Paul Hoffman 
On Mar 10, 2015, at 11:57 PM, Julian Elischer  wrote:
> unfortunatly this makes sendmail incompatible with various email servers 
> around the world,
> including (apparently (ironically (*))) Ironport email gateways.
> It fails in TLS handshake.

Can you say which email servers *other* than unpatched Ironport fail? I've only 
seen it with unpatched Ironport on my (somewhat active) FreeBSD-based mail 
server. FWIW, I only see these bounces in my mail queue for exactly two sites.

Cisco has known about this for many months; see 
. I have been told by an 
Ironport user that there is already a patch that is available from Cisco. If 
that's true (I can't confirm), why would we want to do a patch to our core 
crypto?

--Paul Hoffman
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: sendmail broken by libssl in current

2015-03-11 Thread Dan Lukes 
Paul Hoffman wrote:
> Can you say which email servers *other* than unpatched Ironport fail?

> Cisco has known about this for many months; see 
> 

Note that Bug CSCuo25276 is considered duplicate of the bug CSCuo25329.

> If that's true (I can't confirm), why would we want to do a patch to our core 
> crypto?

Good question. The following should be taken into consideration.

According CSCuo25329, the issue has been fixed on Mar 2,2015 in
8.0.2-055 and 8.5.6-063 release of Cisco Email Security Appliance.

There are three known affected releases only - 8.0.1-023, 8.5.0-473,
8.5.5-280

Dan

___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: sendmail broken by libssl in current

2015-03-11 Thread Gregory Shapiro 
First, thank you Philip for jumping on this.  Much appreciated.

> This wonderful change (cough) to include SSL_OP_TLSEXT_PADDING in 
> SSL_OP_ALL was addressed in sendmail 8.15.1, which explicitly removes 
> SSL_OP_TLSEXT_PADDING from the default ClientSSLOptions value if that 
> #define exists.  I believe Greg is working on importing that to FreeBSD.

sendmail 8.15.1 is imported into the vendor area but not merged due to an 
incompatible change that is being moved into a run-time configuration variable 
in 8.15.2.  Rather than expose the FreeBSD populate to the churn from that 
change, I am skipping 8.15.1 and will import 8.15.2.

That being said, I can certainly make the local fix that Philip mention to take 
care of the padding issue.  Is the new libssl in 11-CURRENT going to be/already 
been MFC'ed to other branches?

___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: DRAM Rowhammer exploits

2015-03-11 Thread Konstantin Belousov 
On Wed, Mar 11, 2015 at 01:11:25AM -0700, Julian Elischer wrote:
> On 3/9/15 12:49 PM, Dmitry Morozovsky wrote:
> > Dear colleagues,
> >
> > any thoughts we're vulnerable to this?
> >
> > http://googleprojectzero.blogspot.ch/2015/03/exploiting-dram-rowhammer-bug-to-gain.html
> >
> one important part of this exploit is the following part:
> ---quote---
> How can we pick pairs of addresses that satisfy the ?different row, 
> same bank? requirements?
> 
> One possibility is to use knowledge of how the CPU?s memory controller 
> maps physical addresses to DRAM?s row, column and bank numbers, along 
> with knowledge of either:
> 
>   * The absolute physical addresses of memory we have access to. Linux
> allows this via /proc//PID//pagemap.
>   * The relative physical addresses of memory we have access to. Linux
> can allow this via its support for ?huge pages?, which cover 2MB
> of contiguous physical address space per page. Whereas a normal 4k
> page is smaller than a typical DRAM row, a 2MB page will typically
> cover multiple rows, some of which will be in the same bank.
> 
> ---end quote---
> I don't know of a similar source of that information in FreeBSD, 
> though near the start of operation one might be able to make a good 
> guess about memory allocation, until ram got too scrambled..
> 
> 
> the "superpages" point would be true in freeBSD as well, tough I 'm 
> not sure how you;d know you had a superpage, but you might be able to 
> do something (file size?) that might make it likely.
> Of course in their first attack it's the location of the data but the 
> location of the page table entry that's important.
> that might be more easily worked out if you allocated a large enough 
> chunk of memory while memory is still predictable.

I just made somewhat dirty port of the double_sided program, available at
https://github.com/kostikbel/rowhammer-test/tree/freebsd

>From what I see, the fetched physical addresses of the mappings look
reasonable, e.g. they are continous for the promoted pages.  Curiously,
my test haswell box does not trip the failure.

There is some weirdness either in the c++ code, or bug in the port, you
might need to use MALLOC_CONF=junk:false setting on head.
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: DRAM Rowhammer exploits

2015-03-11 Thread Mike Tancsa 

On 3/11/2015 2:13 PM, Konstantin Belousov wrote:


I just made somewhat dirty port of the double_sided program, available at
https://github.com/kostikbel/rowhammer-test/tree/freebsd


How many iterations does it usually take to trip up the bug if its there ?

---Mike


--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: DRAM Rowhammer exploits

2015-03-11 Thread Konstantin Belousov 
On Wed, Mar 11, 2015 at 02:30:37PM -0400, Mike Tancsa wrote:
> On 3/11/2015 2:13 PM, Konstantin Belousov wrote:
> 
> > I just made somewhat dirty port of the double_sided program, available at
> > https://github.com/kostikbel/rowhammer-test/tree/freebsd
> 
> How many iterations does it usually take to trip up the bug if its there ?

Look at the original report, AFAIR it has the numbers.
My machine does not exhibit the issue, at least not with the tests
I tried.
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: sendmail broken by libssl in current

2015-03-11 Thread Julian Elischer 

On 3/11/15 7:55 AM, Dan Lukes wrote:

Paul Hoffman wrote:

Can you say which email servers *other* than unpatched Ironport fail?
Cisco has known about this for many months; see 


Note that Bug CSCuo25276 is considered duplicate of the bug CSCuo25329.


If that's true (I can't confirm), why would we want to do a patch to our core 
crypto?

Good question. The following should be taken into consideration.

According CSCuo25329, the issue has been fixed on Mar 2,2015 in
8.0.2-055 and 8.5.6-063 release of Cisco Email Security Appliance.

There are three known affected releases only - 8.0.1-023, 8.5.0-473,
8.5.5-280


well my problem is that I don't know what the other ends are running 
exactly, but they are pretty big institution.
Comonwealth Bank of Australia, and  Western Australian department of 
Education (which shares infrastructure with the rest of the 
government, so, I might as well just say "state of Western Australia".
I don't contact a LOT of large institutions, so given that I had two 
failures over a small sample, and that the documents in each case were 
very important,  I think it's worth some sort of action.  Big 
institutions don't take updates that often, so its hard to know when 
they will update their mail appliances. (they may also not be ironport 
appliances,  I just know those are susceptible).
since hte change is coming in on the next sendmail anyhow I see no 
reason to not take it..



Julian


Dan

___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"




___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: sendmail broken by libssl in current

2015-03-11 Thread Julian Elischer 

On 3/11/15 9:15 AM, Gregory Shapiro wrote:

First, thank you Philip for jumping on this.  Much appreciated.


This wonderful change (cough) to include SSL_OP_TLSEXT_PADDING in
SSL_OP_ALL was addressed in sendmail 8.15.1, which explicitly removes
SSL_OP_TLSEXT_PADDING from the default ClientSSLOptions value if that
#define exists.  I believe Greg is working on importing that to FreeBSD.

sendmail 8.15.1 is imported into the vendor area but not merged due to an 
incompatible change that is being moved into a run-time configuration variable 
in 8.15.2.  Rather than expose the FreeBSD populate to the churn from that 
change, I am skipping 8.15.1 and will import 8.15.2.

That being said, I can certainly make the local fix that Philip mention to take 
care of the padding issue.  Is the new libssl in 11-CURRENT going to be/already 
been MFC'ed to other branches?

___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"



the change is in libssl1.0.1g and later
so, yes it's already in 10

___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: sendmail broken by libssl in current

2015-03-11 Thread Paul Hoffman 
On Mar 11, 2015, at 9:15 AM, Gregory Shapiro  wrote:
> First, thank you Philip for jumping on this.  Much appreciated.
> 
>> This wonderful change (cough) to include SSL_OP_TLSEXT_PADDING in 
>> SSL_OP_ALL was addressed in sendmail 8.15.1, which explicitly removes 
>> SSL_OP_TLSEXT_PADDING from the default ClientSSLOptions value if that 
>> #define exists.  I believe Greg is working on importing that to FreeBSD.
> 
> sendmail 8.15.1 is imported into the vendor area but not merged due to an 
> incompatible change that is being moved into a run-time configuration 
> variable in 8.15.2.  Rather than expose the FreeBSD populate to the churn 
> from that change, I am skipping 8.15.1 and will import 8.15.2.
> 
> That being said, I can certainly make the local fix that Philip mention to 
> take care of the padding issue.  Is the new libssl in 11-CURRENT going to 
> be/already been MFC'ed to other branches?

I'm still *really* hesitant for us to be patching OpenSSL for a bug on a 
middlebox vendor's system that already has a fix.

--Paul Hoffman
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: sendmail broken by libssl in current

2015-03-11 Thread Gregory Shapiro 
> > sendmail 8.15.1 is imported into the vendor area but not merged due to an 
> > incompatible change that is being moved into a run-time configuration 
> > variable in 8.15.2.  Rather than expose the FreeBSD populate to the churn 
> > from that change, I am skipping 8.15.1 and will import 8.15.2.
> > 
> > That being said, I can certainly make the local fix that Philip mention to 
> > take care of the padding issue.  Is the new libssl in 11-CURRENT going to 
> > be/already been MFC'ed to other branches?
> 
> I'm still *really* hesitant for us to be patching OpenSSL for a bug on a 
> middlebox vendor's system that already has a fix.

My intent is to patch sendmail, not OpenSSL, with a change that is already part 
of a newer sendmail release.
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: sendmail broken by libssl in current

2015-03-11 Thread Paul Hoffman 
On Mar 11, 2015, at 12:25 PM, Gregory Shapiro  wrote:
> 
>>> sendmail 8.15.1 is imported into the vendor area but not merged due to an 
>>> incompatible change that is being moved into a run-time configuration 
>>> variable in 8.15.2.  Rather than expose the FreeBSD populate to the churn 
>>> from that change, I am skipping 8.15.1 and will import 8.15.2.
>>> 
>>> That being said, I can certainly make the local fix that Philip mention to 
>>> take care of the padding issue.  Is the new libssl in 11-CURRENT going to 
>>> be/already been MFC'ed to other branches?
>> 
>> I'm still *really* hesitant for us to be patching OpenSSL for a bug on a 
>> middlebox vendor's system that already has a fix.
> 
> My intent is to patch sendmail, not OpenSSL, with a change that is already 
> part of a newer sendmail release.

Ah, that wasn't clear from the thread, sorry. Sure, patching Sendmail for this 
seems fine. Thanks!

--Paul Hoffman
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: sendmail broken by libssl in current

2015-03-11 Thread Dan Lukes 
Julian Elischer wrote:
>>> Can you say which email servers *other* than unpatched Ironport fail?

> well my problem is that I don't know what the other ends are running
> exactly, but they are pretty big institution.

Just side note - you need not to wait for a source patch. Just disable
TLS for those destinations as a instant workaround.

Users of 8.4/9.3 need to disable TLS to those destinations supporting
TLSv1.2 only (as TLSv1.2 is not supported by sendmail on 8.4/9.3-R), so
you will not be alone with such kind of workaround ;-)

Dan


___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"