reencrypts the
key w/ a larger number of rounds (and overwrites the backup)... This
would also make it easier to upgrade KDFs if a newer/better one is
added.
[1]
https://crypto.stackexchange.com/questions/26510/why-is-hmac-sha1-still-considered-secure
--
John-Mark Gurney
also:
https://cgit.freebsd.org/src/commit/?id=64cbf7cebc3b80a971e1d15124831d84604b9370
FreeBSD just merged in OpenSSL 1.1.1q
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
ave to be updated to support it, and this method
can be done via an update to the ca_root_nss package which is less
invasive than the above patch.
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have,
Dan Lukes wrote this message on Fri, Feb 26, 2021 at 08:41 +0100:
> On 26.2.2021 2:07, John-Mark Gurney wrote:
> >> Third party CA's are an untrusted automagical nightmare of global and
> >> local MITM risk...
> >
> > Do you delete all the CA's from your
arch web for howtos.
>
> At minimum require user / install to ack before use...
> mv /etc/ssl/certs.shipped_disabled /etc/ssl/certs
Last I checked no browser requires users to ack to install those CA's
have you attempted to pressure them to?
I'm personally much happier to have the
Benjamin Kaduk wrote this message on Sat, Dec 12, 2020 at 18:07 -0800:
> On Sat, Dec 12, 2020 at 04:57:08PM -0800, John-Mark Gurney wrote:
> >
> > If FreeBSD is going to continue to use OpenSSL, better testing needs to
> > be done to figure out such breakage earliers, and
John Baldwin wrote this message on Sat, Dec 12, 2020 at 11:40 -0800:
> On 12/10/20 10:46 PM, John-Mark Gurney wrote:
> > FreeBSD Security Advisories wrote this message on Wed, Dec 09, 2020 at
> > 23:03 +:
> >> versions included in FreeBSD 12.x. This vulnerability is a
Benjamin Kaduk wrote this message on Fri, Dec 11, 2020 at 12:38 -0800:
> On Thu, Dec 10, 2020 at 10:46:28PM -0800, John-Mark Gurney wrote:
> > FreeBSD Security Advisories wrote this message on Wed, Dec 09, 2020 at
> > 23:03 +:
> > > versions included in FreeBSD 12.x
Robert Schulze wrote this message on Fri, Dec 11, 2020 at 10:14 +0100:
> Hi,
>
> Am 11.12.20 um 07:46 schrieb John-Mark Gurney:
> >
> > Assuming 13 releases w/ OpenSSL, we'll be even in a worse situation
> > than we are now. OpenSSL 3.0.0 has no support c
with 1.1.1 for 13 will put us even in a worse
situation than we are today.
What are peoples thoughts on how to address the support mismatch between
FreeBSD and OpenSSL? And how to address it?
IMO, FreeBSD does need to do something, and staying w/ OpenSSL does
not look like a
rity issues in that report as well, so it
isn't like the report found security vulnerability in every TCP/IP
stack they tested.
The best way to have confidence is to pay people to analyize and
verify that the FreeBSD TCP/IP stack is secure, just as it is w/
any c
r.
Don't have a strong opinion on this...
> I???ll be in touch with ip2locatiin as well
>
> --
> J. Hellenthal
>
> The fact that there's a highway to Hell but only a stairway to Heaven says a
> lot about anticipated traffic volume.
>
> > On Nov 14, 2020, at
add -f [???]
> No ALTQ support in kernel
> ALTQ related functions disabled
> no IP address found for 2001:BB6:6A10:4200:58D7:5934:7
Well, this isn't a valid ipv6 address. There are only 7 segments,
where as an ipv6 address needs 8. There is not a :: to fill o
ntication by itself does not trust the network or
name servers or anything (but the key); however, if somebody
somehow steals the key, the key permits an intruder to log in
from anywhere in the world. This additional option makes using a
stolen key more d
y
> > objections. It's good to have options.
>
> Yes, pulling in scrypt and/or argon2 is a great idea...
>
> --
> John-Mark GurneyVoice: +1 415 225 5579
>
> "All that I will do, has been done, All that I have, has not.&q
to have options.
Yes, pulling in scrypt and/or argon2 is a great idea...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
___
freebsd-security
relevant kernel fault
> handler,
> following each such fault?
Randomization only makes it harder, not impossible to detect the timing
impact. You just need to collect more samples to average out the noise.
--
John-Mark Gurney Voice: +1 415 225 5579
&quo
NOT give access
> to kernel memory).
No, Spectre does not allow one userland process to read another userland
process's memory.. It allows an attacker to read any memory within the
same process..
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I
Considering that China has redirected large segments of the inet traffic
through them, you can't even trust the inet back bone to be secure. I
know I've never gotten notification from my ISP that my traffic may have
been compromised this way, and w/o notification, I cannot properly as
Igor Mozolevsky wrote this message on Sun, Dec 10, 2017 at 19:17 +:
> On 10 December 2017 at 19:02, John-Mark Gurney wrote:
>
> > Igor Mozolevsky wrote this message on Sun, Dec 10, 2017 at 17:39 +:
> > > On 10 December 2017 at 17:32, Jo
Igor Mozolevsky wrote this message on Sun, Dec 10, 2017 at 17:39 +:
> On 10 December 2017 at 17:32, John-Mark Gurney wrote:
>
>
>
> > The discussion has been for svn updates over http, not for freebsd-update
> > updates which are independantly signed and verifi
Poul-Henning Kamp wrote this message on Sun, Dec 10, 2017 at 17:36 +:
>
> In message <20171210172127.gd5...@funkthat.com>, John-Mark Gurney writes:
> >Michelle Sullivan wrote this message on Fri, Dec 08, 2017 at 21:29 +1100:
> >> Sorry you want to ensure a
verified.. There is currently
no signatures provided via SVN to validate any source received via http.
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
___
use
Comcast modifies traffic. So you're now saying that if you use FreeBSD
you can't use Comcast as your ISP?
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
g svn updates to be done so?
The arguments that it takes up resources is true, but it is NOT
significant... End users are often bandwidth limited, NOT CPU
limited...
[1]
https://www.techdirt.com/articles/20161123/10554936126/comcast-takes-heat-injecting-messages-into-internet-traffic.shtml
--
ed the
options it provides. It increases driver complexity to support the
many different ways that encryption and mac algorithms can be ordered...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
__
it will, at worst, just have read-only access to my
> content files.
Best way to assume is that the network is always compromized, and that
it's up to the nodes to protect the data...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, h
ter to ask how this is possible.
[1] https://en.wikipedia.org/wiki/Public_key_infrastructure
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
__
Ben Woods wrote this message on Wed, Nov 11, 2015 at 16:27 +0800:
> On Wednesday, 11 November 2015, John-Mark Gurney wrote:
>
> > Ben Woods wrote this message on Wed, Nov 11, 2015 at 15:40 +0800:
> > > I have to agree that there are cases when the NONE cipher makes sense,
&
MAC is still the long poll when
it comes to encryption w/ AES-NI...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
___
freebsd-security@freebsd.org m
Ben Woods wrote this message on Wed, Nov 11, 2015 at 15:40 +0800:
> On Wednesday, 11 November 2015, Bryan Drewery wrote:
>
> > On 11/10/15 9:52 AM, John-Mark Gurney wrote:
> > > My vote is to remove the HPN patches. First, the NONE cipher made more
> > > sense b
Bryan Drewery wrote this message on Tue, Nov 10, 2015 at 16:32 -0800:
> On 11/10/15 9:52 AM, John-Mark Gurney wrote:
> > My vote is to remove the HPN patches. First, the NONE cipher made more
> > sense back when we didn't have AES-NI widely available, and you were
> >
ove
that the HPN patches do make a difference, I'm willing to work with
them to figure out why my tests didn't work and change my vote. I
also believe that the defaults should be enough, if you have to tune
or enable features, then you can install from ports or compile yourself.
--
Joh
, in my opinion.
Then you get projects like certificate pinning and SSL Observatory that
helps ensure that the cert that is presented is also presented to others...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I
John-Mark Gurney wrote this message on Wed, Jul 29, 2015 at 09:11 -0700:
> George Neville-Neil wrote this message on Wed, Jul 29, 2015 at 10:35 -0400:
> > That's fine so long as its removed in HEAD now, and then the warning can
> > go into 10 aka 10.3.
>
> As I said,
l 2015, at 13:25, Adrian Chadd wrote:
>
> > I'd put together a deprecation plan, which starts with the kernel
> > warning that this stuff is being removed, MFC that to stable/10 and
> > stable/9 so people aren't surprised when they upgrade, and
ddleopenvpn-exit-node-mit-jails/
>
> or the racoon example from:
> https://blog.plitc.eu/2014/freebsd-10-ipv4-ipsec-net-to-net-vpn-in-der-jail/
>
> best regards
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I wil
Jim Thompson wrote this message on Mon, Jul 27, 2015 at 23:18 -0500:
> > On Jul 27, 2015, at 10:41 PM, John-Mark Gurney wrote:
> >
> > Jim Thompson wrote this message on Mon, Jul 27, 2015 at 20:24 -0500:
> >>> On Jul 27, 2015, at 7:57 PM, John-Mark Gurney wrote
Jim Thompson wrote this message on Mon, Jul 27, 2015 at 20:24 -0500:
> > On Jul 27, 2015, at 7:57 PM, John-Mark Gurney wrote:
> >
> > I would like to remove it from HEAD immediately as I don't see a use
> > for it. Some time ago I proposed removing Ski
nt to keep this mode, you have to say you are currently
using the mode and include a working sample config.
Thanks.
[1] https://tools.ietf.org/html/draft-ietf-ipsec-skipjack-cbc-00
[2] https://en.wikipedia.org/wiki/Skipjack_(cipher)
--
John-Mark Gurney Voice:
a TAI-based time_t and a
> POSIX-based time_t.
Though from my reading of the code, you need to have TZ files compiled
w/ leap seconds which FreeBSD doesn't do by default...
--
John-Mark Gurney Voice: +1 415 225 5579
"
ds crypto(4), but does not use cryptodev(4) - at least, that's what
> I gather from the man page.
Correct... It is safe to load crypto(4) and aesni(4)... and
cryptodev(4) isn't needed for geli to use the aesni module...
--
John-Mark Gurney Voice: +1 415 225 55
Kevin Day wrote this message on Sun, May 24, 2015 at 23:15 -0500:
> > On May 24, 2015, at 5:44 PM, John-Mark Gurney wrote:
> >
> > If you have cryptodev loaded, this is to be expected as OpenSSL will
> > use /dev/crypto instead of the AES-NI instructions.. Just don&
16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes
> aes-256-cbc 4662.35k17964.33k59148.60k 145272.15k 208882.35k
>
>
> Is this expected here, or is something broken?
If you have cryptodev loaded, this is to be expected as OpenSSL will
use /d
our opinion ?
Having working on the AES-XTS code, and looked at the geli code to make
it go faster, it's good code.. I don't see any major issues w/ it
besides what is well know w/ using the various modes...
--
John-Mark Gurney Voice: +1 415 2
ing '\0' afterward instead of strncpy(). It
> seems unnecessary to clear the buffer completely.
I had thought of both of these before, and agree that the salt is not
a secret (it is kept hidden), but, it leaks information, and _makesalt
is called so rarely, that saving the time doesn&#
got around to reviewing this...
For the tests, we should probably add an invalid password test for
each format...
We need man pages for the new function... I guess this new man
page would be a good place to document all the modular formats in
more detail.. what is in crypt(3) isn't that usefu
are of interest.
Thanks, I've taken this offer off list.
> > On Feb 6, 2015, at 6:35 PM, John-Mark Gurney wrote:
> >
> > I have some plans to improve the opencrypto framework in FreeBSD later
> > this year. This will require invasive changes to the various d
glxsb (AMD Geode LX, such as Sokris Net5501, missing man page)
safe (SafeNet)
sec (Freescale, missing man page)
cryptocteon (Cavium Octeon, missing man page)
nlmsec (mips/nlm/dev/sec/nlmsec.c, missing man page)
rmisec (mips/rmi/dev/sec/rmisec.c, missing man page)
--
John-Mark G
Andrey V. Elsukov wrote this message on Fri, Nov 21, 2014 at 01:20 +0300:
> On 21.11.2014 00:35, John-Mark Gurney wrote:
> > As I'm about to commit my AES-GCM work, I've been trying to do
> > some testing to make sure I didn't break IPsec.
> >
> > The fi
s
now that weren't used back then that should get us around this issue..
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
___
freebsd-security@freebsd.org m
Andrey V. Elsukov wrote this message on Mon, Nov 17, 2014 at 21:34 +0300:
> On 16.11.2014 09:15, John-Mark Gurney wrote:
> > Ok, I was able to reproduce the bug, and found that my optimization
> > for single mbuf packets was broken... I've attached a new patch
Adrian Chadd wrote this message on Sat, Nov 15, 2014 at 22:18 -0800:
> ... no attachment?
Thanks, I put it on the website since I realized it was 155k and
a bit large to attach...
it's at:
https://www.funkthat.com/~jmg/patches/aes.ipsec.6.patch
> On 15 November 2014 22:15, John-
Andrey V. Elsukov wrote this message on Sat, Nov 15, 2014 at 15:19 +0300:
> On 15.11.2014 05:42, John-Mark Gurney wrote:
> > I just verified that this happens on a clean HEAD @ r274534:
> > FreeBSD 11.0-CURRENT #0 r274534: Fri Nov 14 17:17:10 PST 2014
> > j...@carbon.funk
John-Mark Gurney wrote this message on Fri, Nov 14, 2014 at 11:39 -0800:
> Well.. It looks like IPSEC is still broken in head... I can get
> pings to pass, but now on IPv4 transport mode, I can't get syn's to
> be sent out... I see the output packet in the protocol stats, but
Vsevolod Stakhov wrote this message on Sat, Nov 08, 2014 at 21:20 +:
> On 08/11/14 20:45, John-Mark Gurney wrote:
> >Vsevolod Stakhov wrote this message on Sat, Nov 08, 2014 at 18:55 +:
> >>On 08/11/14 04:23, John-Mark Gurney wrote:
> >>>Hello,
> >&g
Vsevolod Stakhov wrote this message on Sat, Nov 08, 2014 at 18:55 +:
> On 08/11/14 04:23, John-Mark Gurney wrote:
> > Hello,
> >
> > Over the last few months, I've been working on a project to add support
> > for AES-GCM and AES-CTR modes to our Op
f) so multisegmented
inputs don't have to be copied.
I know there are more fixes and future improvements, but can't think of
them now.
Ermal (eri) has patches that enable AES-GCM (and I believe AES-CTR)
support for our IPsec. Once these patches have been committed, I'll
work with him
Paul Hoffman wrote this message on Sun, Sep 07, 2014 at 07:00 -0700:
> On Sep 5, 2014, at 3:25 PM, John-Mark Gurney wrote:
>
> > Skipjack: already removed by OpenBSD and recommend not for use by NIST
> > after 2010, key size is 80 bits
>
> Yes, nuke.
>
> >
emove
them from their use w/ IPSec. Most other systems are userland and will
use OpenSSL which is different.
It would be possible for parties that need support to make them a
module, but right now, if you compile in crypto into your kernel, you
get all of these ciphers...
Comments?
Thanks.
Konstantin Belousov wrote this message on Sat, Jul 19, 2014 at 22:26 +0300:
> On Sat, Jul 19, 2014 at 12:03:48PM -0700, John-Mark Gurney wrote:
> > So, my suggestions:
> > 1) Convert arc4random(9) in the kernel to use the random pool as
> > /dev/random uses. I vaguely r
arc4random(3) to use the sysctl, and if the sysctl fails,
kill the process.
There are also some other improvements that can be made to the
/dev/random frame work, but those are more code cleanup, not security
related changes...
--
John-Mark Gurney Voice:
Jonathan Anderson wrote this message on Fri, Jul 04, 2014 at 10:00 -0230:
> John-Mark Gurney wrote:
> >Dan Lukes wrote this message on Thu, Jul 03, 2014 at 02:26 +0200:
> >>If I consider a CA to be trustworthy, I will insert it's certificate to
> >>trusted store.
s to issue a warning, but go ahead anyways as if
--no-verify-peer is specified? That is assuming we don't install one
by default...
I normally use wget which has the same issue, so I usually spell it
--no-check-certificate...
--
John-Mark Gurney Voice: +1 415 2
rse if we install a CA bundle, this does mean someone who
uses lynx or other text based browser might now not get warnings
about untrusted banking sites, but again, the CA bundle is primarily
to increase the usability/reliability of fetch, not protecting
banking sites...
--
John-Mark Gurney
re willing to do that...
> Are you ready to recommend a CA as trustworthy and take responsibility
> for such advice ?
>
> OK, I expressed my personal opinion in full and I'm not wishing to start
> a flame war here ;-)
It's good to know the conserns o
... If it's mirror mozzila's cert repo, then
that's fine, but if we don't have a policy, what will we do when other
CA's contact someone at FreeBSD wanting to get their cert included by
default?
--
John-Mark Gurney Voice: +1 415 225 5579
John-Mark Gurney wrote this message on Wed, Jun 25, 2014 at 18:22 -0700:
> Subj is more limited by your attack profile, than purely fast crypto..
> In some cases the crypto can be made reasonably fast while being
> secure against side channel analysis, but in other cases (GHASH) it's
John-Mark Gurney wrote this message on Wed, Jun 25, 2014 at 18:22 -0700:
> Subj is more limited by your attack profile, than purely fast crypto..
> In some cases the crypto can be made reasonably fast while being
> secure against side channel analysis, but in other cases (GHASH) it's
e the choice...
Comments?
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/m
operly
translated to the CPU and memory model of said CPU...
So, as long as condition is an object that is not volatile (or accessed
through volatile pointers), it's state cannot change, and there for is
the equivalent to if/else, though the definition of condition was left
out making this hard t
quot; in this context.
>
> Have a look at the ~10.000 reports at
> http://scan.freebsd.your.org/freebsd-head/ (unavailable ATM). Silly things
> are reported like missing return at the end of main()
Considering that this is legal C99, it is very silly, from 5.1.2.2.3 of
using function returns using more than a
> few dozen bytes of stack space to erase the newly freed stack region
> just prior to resuming the caller.
there is an option to do this w/ malloc(3):
J Each byte of new memory allocated by malloc(), realloc(), or
reallo
in base...
yes, there is pkg there, how are you going to fetch packages to install
if you don't have that?
btw, all found w/ ldd /usr/bin/* /usr/sbin/* 2>/dev/null | less and
searching for libssl...
--
John-Mark Gurney Voice: +1 415 225 5579
"All
John-Mark Gurney wrote this message on Tue, Feb 11, 2014 at 10:56 -0800:
> I did some performance testing on sha256, and found that the libmd
> version is significantly faster, ~20%, than the kernel version. Even
> if you enable SHA2_UNROLL_TRANSFORM (which isn't the default), th
cle, a pointer to
> it would be useful to me (and maybe others).)
Basicly we don't drain the entropy pool as quickly, leaving better
entropy in the system, and preventing an attacker from not having to
do as much work controlling external inputs to the system to possibly
attack the pool.
Dag-Erling Smrgrav wrote this message on Fri, Sep 13, 2013 at 12:24 +0200:
> John-Mark Gurney writes:
> > for kernel malloc, look at sys/kern_malloc.c.. It doesn't look like
> > there is a knob to turn on kernel malloc filling, but it wouldn't be
> > hard...
>
gt;> there is NO OS in the world that can survive that test if they are
> > talking
> > >> about protection from a malware kernel module.
> > >> On the other hand if they are just talking about user memory allocation
> > >> then of course we NEVER hand u
nificant...
> On Sep 11, 2013, at 7:35 PM, John-Mark Gurney wrote:
>
> > Jonathon Wright wrote this message on Wed, Sep 11, 2013 at 14:15 -1000:
> >> I have posted this question (username-scryptkiddy) in the forums:
> >> http://forums.freebsd.org/showthread.php?t=
al.org:80/files/epfiles/nCircle%20CR%20v1.0.pdf
It is possible someone else has received certification on a newer version,
but I'm not aware of any at this time...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that
tm) HD Graphics(3393.89-MHz K8-class CPU)
I guess now we need to figure out how to teach OpenSSL to use AES-NI
natively even when /dev/crypto is available...
but at least we did solve the (non-)issue of bad OpenSSL performance...
I will submit a patch to OpenSSL to not make the documentation o
7;m guessing we have an issue there...
I discovered a similar issue on HEAD w/ 1.0.1e where openssl speed -engine
aes-256-cbc when ktraced would not issue any ioctl's during the speed
test... You can see that it opens the device, but then it gets a number
of failures:
11466 openssl CALL ioc
Depending upon where the overflow happens, it could make it even easier
to exploit... If the overflow happens in the header part, then the http
accept filter will make it even easier, and not require the attacker to
do tricks at the TCP layer...
--
John-Mark Gurney Vo
83 matches
Mail list logo
