Skip site navigation (1)Skip section navigation (2) 
Date:      Tue, 12 Dec 2017 08:48:20 -0600
From:      Karl Denninger <karl@denninger.net>
To:        freebsd-security@freebsd.org
Subject:   Re: http subversion URLs should be discontinued in favor of https URLs
Message-ID:  <6fff232c-65c0-34bc-a950-0e79eda025c8@denninger.net>
In-Reply-To: <26440.1513088888@critter.freebsd.dk>
References:  <20171205231845.5028d01d@gumby.homeunix.com> <CADWvR2gVn8H5h6LYB5ddwUHYwDtiLCuYndsXhJywi7Q9vNsYvw@mail.gmail.com> <20171210173222.GF5901@funkthat.com> <CADWvR2iGQOtcU=FnU-fNsso2eLCCQn=swnOLoqws%2B33V8VzX1Q@mail.gmail.com> <5c810101-9092-7665-d623-275c15d4612b@rawbw.com> <CADWvR2j_LLEPKnSynRRmP4LG3mypdkNitwg%2B7vSh=iuJ=JU09Q@mail.gmail.com> <fd888f6b-bf16-f029-06d3-9a9b754dc676@rawbw.com> <CADWvR2jnxVwXmTA9XpZhGYnCAhFVifqqx2MvYeSeHmYEybaNnA@mail.gmail.com> <19bd6d57-4fa6-24d4-6262-37e1487d7ed6@rawbw.com> <5A2DB80D.3020309@sorbs.net> <20171210225326.GK5901@funkthat.com> <99305.1512947694@critter.freebsd.dk> <86d13kgnfh.fsf@desk.des.no> <79567.1513083576@critter.freebsd.dk> <c27552cf-45d8-7686-c60d-256537780edc@denninger.net> <26440.1513088888@critter.freebsd.dk>
index | next in thread | previous in thread | raw e-mail 

[-- Attachment #1 --]
On 12/12/2017 08:28, Poul-Henning Kamp wrote:
> --------
> In message <c27552cf-45d8-7686-c60d-256537780edc@denninger.net>, Karl Denninger
>  writes:
>
>> Now the question becomes this -- is the proper means to handle this via
>> TLS (using that root cert) OR should the *transport* be fixed so that
>> https doesn't need to be used?
> I certainly would caution against inventing more encrypted transports
> than we already have.
>
> The only feasible alternative I see is SSH, provided we can persuade
> it somehow to not authenticate the client.
>
> If this requires a hacked sshd(8) which just says "welcome" I would
> be very worried about it coexisting with a untainted sshd on any
> system.
I generally disagree with doing this at the transport level *at all*
since it's quite-arguably the wrong place to do it and further it
provides an alleged "verification" you not only don't need but maybe
don't want (e.g. do you CARE if the bits come from the project's server
directly or not?  No.  You only care that they weren't tampered with.)
>> I argue the second, because the goal when it comes to source
>> distributions is ensuring that the code you transfer is bit-wise
>> identical to the code on the FreeBSD project repositories *which can be
>> mirrored.*
> I am personally a very big fan of integrity checks which does not
> also encrypt the content with an ephemeral key for exactly that
> reason.
>
> Most of the people who try to force everything behind HTTPS don't
> even know you can do that.
>
> For the FreeBSD SVN tree, this could almost be as simple as posting
> an email, maybe once a week, with the exact revision checked out
> and the PGP signed output of:
>
> 	svn co ... && find ... -print | sort | xargs cat | sha256
>
> Such an archive would also be invaluable for reauthenticating in
> case, somebody ever manages to do something evil to our repo.
That's a halfway hack but a pretty easy one.....
>> Solve the problem at the correct location -- either fix svn to sign and
>> verify updates or dump it for something that can and use that existing
>> mechanism (e.g. git)
> As I mentioned humoursly to you in private email, I don't think
> this particular problem will reach consensus any sooner if you 
> also tangling it in the SVN vs GIT political issue.
Fair enough but I think my underlying point -- that svn ought to provide
the ability to distribute signed bits, and if it can't then it should
either be wrapped or augmented to do so if possible, and tossed if not,
remains valid.

Offering encrypted transport as an option is good but it fails at
providing the actual attestation you want (that the bits the project
committed and has on its disk are the bits you received and stored on
your disk, unaltered.)

Removing unencrypted transport is thus IMO a net bad as it *claims* to
address this but doesn't.  That's bad because you now lead people to
*believe* they have a secure means of tracking the project's bits but
that's factually false.

Specifically if I have a mirror of the svn repo today and I
intentionally corrupt it (e.g. to insert a back door in "su") then I can
have a perfectly-valid TLS/SSL certificate and serve you an exact copy
of the bits on my disk but since I corrupted the bits on the disk you
still get screwed!

Signed commits prohibit this sort of chicanery in that I cannot generate
the project's signature.  They thus make possible known-good mirrors of
the code repo that do not have to be under the physical control of the
FreeBSD project.  This extends the existing capability to verify
-RELEASE distributions on a mirror to the source, which IMHO is a net
good and thus if we're talking about the context of source distribution
security it is where attention should be focused.

-- 
Karl Denninger
karl@denninger.net <mailto:karl@denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/

[-- Attachment #2 --]
0	*H
010
	`He0	*H

00H^Ōc!5
H0
	*H
010	UUS10UFlorida10U	Niceville10U
Cuda Systems LLC10UCuda Systems CA1!0UCuda Systems LLC 2017 CA0
170817164217Z
270815164217Z0{10	UUS10UFlorida10U
Cuda Systems LLC10UCuda Systems CA1%0#UCuda Systems LLC 2017 Int CA0"0
	*H
0
h-5B>[;olӴ0~͎O9}9Ye*$g!ukvʶLzN`jL>MD'7U45CB+kY`bd~b*c3Ny-78ju]9HeuέsӬDؽmgwER?&UURj'}9nWD i`XcbGz\gG=u%\Oi13ߝ4
K44pYQr]Ie/r0+eEޝݖ0C15Mݚ@JSZ(zȏNTa(25DD5.l<g[[ZarQQ%Buȴ~~`IohRbʳڟu2MS8EdFUClCMaѳ!}ș+2k/bųE,n当ꖛ\(8WV8	d]b	yXw	܊:I39
00U]^§Q\ӎ0U#0T039N0b010	UUS10UFlorida10U	Niceville10U
Cuda Systems LLC10UCuda Systems CA1!0UCuda Systems LLC 2017 CA	@Ui0U00U0
	*H
:P U!>vJnio-#ן]WyujǑR̀Q
nƇ!GѦFg\yLxgw=OPycehf[}ܷ['4ڝ\[p6\o.B&JF"ZC{;*o*mcCcLY߾`
t*S!񫶭(`]DHP5A~/NPp6=mhk밣'doA$86hm5ӚS@jެEgl
)0JG`%k35PaC?σ
׳HEt}!P㏏%*BxbQwaKG$6h¦Mve;[o-Iی&
I,Tcߎ#t wPA@l0P+KXBպT	zGv;NcI3&JĬUPNa?/%W6G۟N000k#Xd\=0
	*H
0{10	UUS10UFlorida10U
Cuda Systems LLC10UCuda Systems CA1%0#UCuda Systems LLC 2017 Int CA0
170817212120Z
220816212120Z0W10	UUS10UFlorida10U
Cuda Systems LLC10Ukarl@denninger.net0"0
	*H
0
T[I-ΆϏdn;Å@שy.us~_ZG%<MYd\gvfnsa1'6Egyjs"C [{~_KPn+<*pv#Q+H/7[-vqDV^U>f%GX)H.|l`M(Cr>е͇6#odc"YljҦln8@5SA0&ۖ"OGj?UDWZ5	dDB7k-)9Izs-JAv
J6L$Ն1SmY.Lqw*SH;EF'DĦH]MOgQQ|Mٙג2Z9y@y]}6ٽeY9Y2xˆ$T=eCǺǵbn֛{j|@LLt1[Dk5:$=	`	M00<+00.0,+0 http://ocsp.cudasystems.net:88880	U00	`HB0U0U%0++03	`HB
&$OpenSSL Generated Client Certificate0U%՞V=؁;bzQ0U#0]^§Q\ӎϡ010	UUS10UFlorida10U	Niceville10U
Cuda Systems LLC10UCuda Systems CA1!0UCuda Systems LLC 2017 CAH^Ōc!5
H0U0karl@denninger.net0
	*H
۠A0-j%--$%g2#ޡ1^>{K+uGEv1ş7Af&b&O;.;A5*U)ND2bF|\=]<sˋL!wrw٧>YMÄ3\mWR hSv!_zvl? 3_ xU%\^#O*Gk̍YI_&Fꊛ@&1n”} ͬ:{hTP3B.;bU8:Z=^Gw8!k-@xE@i,+'Iᐚ:fhztX7/(hY` O.1}a`%RW^akǂpCAufgDixUTЩ/7}%=jnVZvcF<M=
2^GKH5魉
_O4ެByʈySkw=5@h.0z>
W1000{10	UUS10UFlorida10U
Cuda Systems LLC10UCuda Systems CA1%0#UCuda Systems LLC 2017 Int CAk#Xd\=0
	`HeE0	*H
	1	*H
0	*H
	1
171212144820Z0O	*H
	1B@LP'"%)>r3yPN >J%-_o^Tl	jjSgV80l	*H
	1_0]0	`He*0	`He0
*H
0*H
0
*H
@0+0
*H
(0	+7100{10	UUS10UFlorida10U
Cuda Systems LLC10UCuda Systems CA1%0#UCuda Systems LLC 2017 Int CAk#Xd\=0*H
	10{10	UUS10UFlorida10U
Cuda Systems LLC10UCuda Systems CA1%0#UCuda Systems LLC 2017 Int CAk#Xd\=0
	*H
n1kԭspkvq@E7%!}1a߄\u	zG7>u'Ps+:
s4(nn oHOIwi\/[0u-{TKޞ9dKZr	@.^5@uX$8;Pa`-YOAO&Qt㇫b	C*KP7לWDEd\s3N=[7=Ȋ%UqjfV<nl=OGf}°SRqݪ*xga#3ٽ&3;ҭoޥ^;ZТ?/?~uvdy٢`&/pKPS'`JYVC7ƩO m6Kt&6gRTZ$2Ix$jIpƁU!?@jJ
1aC`h
~Po@A+yxB<ڙmu9bs
help

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6fff232c-65c0-34bc-a950-0e79eda025c8>