Re: http subversion URLs should be discontinued in favor of https URLs

[Cy Schubert]

In message <201712150610.vbf6ail0073...@donotpassgo.dyslexicfish.net>, 
Jamie La
ndeg-Jones writes:
> Gordon Tetlow  wrote:
>
> > I want to move the default for svn to be HTTPS. This would mean setting
> > up a redirect on http://svn.freebsd.org -> https://svn.freebsd.org. For
>
> Blimey! You're either very brave, or haven't read the thread fully! :-)

This discussion reminds me of some of my clients in which telnet, telnetd, 
ftp, and ftpd are not installed without departmental SO and CIO approval.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX:     Web:  http://www.FreeBSD.org

The need of the many outweighs the greed of the few.


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

Re: http subversion URLs should be discontinued in favor of https URLs

[Poul-Henning Kamp]

In message <20171215050430.gt9...@gmail.com>, Gordon Tetlow writes:

>Running a Root CA brings a huge amount of baggage and we are not mature
>enough in policy to build in a manner that would align with established
>practice for running a Root CA.

Since we would not be protecting People Who Can Sue Use For Big Damages
data, we wouldn't need to run a Root CA to that practice, which is mostly
about Blame Allocation and very little about actual security.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: http subversion URLs should be discontinued in favor of https URLs

[Jamie Landeg-Jones]

Gordon Tetlow  wrote:

> I want to move the default for svn to be HTTPS. This would mean setting
> up a redirect on http://svn.freebsd.org -> https://svn.freebsd.org. For

Blimey! You're either very brave, or haven't read the thread fully! :-)
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: http subversion URLs should be discontinued in favor of https URLs

[Gordon Tetlow]

On Wed, Dec 13, 2017 at 01:29:26PM -0800, Peter Wemm wrote:
> On 12/12/17 5:38 PM, Yuri wrote:
> > On 12/12/17 16:37, Peter Wemm wrote:
> >> I think you're missing the point.  It is a sad reality that SSL/TLS 
> >> corporate
> >> (and ISP) MITM exists and is enforced on a larger scale than we'd like.  
> >> But
> >> it is there, and when mandated/enforced you have to go through the MITM
> >> appliance, or not connect at all.  Private CA's generally break those
> >> appliances - an unfortunate FreeBSD user in this situation is cut off.  
> >> How is
> >> this better?
> > 
> > 
> > This is certainly better for users because it informs the user. Now he has 
> > a choice to use a special override key to use MITMed https anyway or 
> > refuse, vs. with http he is not informed.
> 
> You misunderstand the problem.
> 
> A well-behaving corporate with TLS MITM will *block* connections to the 
> freebsd-ca signed services as they will fail it's validation.
> 
> The user is left with:
>   * can't connect on 443 (proxy blocks failed validations), or
>   * can't connect on 80 (because you don't like people having options).
> .. which leads to stop using FreeBSD.

I'm going to put my SO hat on here for a second, put on the flame
retardant suit, and make the following statement:

I want to move the default for svn to be HTTPS. This would mean setting
up a redirect on http://svn.freebsd.org -> https://svn.freebsd.org. For
those people that are unable (for whatever reason) to use HTTPS, we can
make a vhost they are able to use HTTP on. I would suggest something
like: http://i-love-waffles-and-svn-over-http.freebsd.org. (Waffles are
awesome.) The CA for this HTTPS server should be the standard publicly
trusted CA we use for everything (Let's Encrypt).

We can debate the brokeness of the current CA system (and I completely
agree there is a ton of brokeness there), but it is the system we have
today. We should follow industry best practice here.

Running a Root CA brings a huge amount of baggage and we are not mature
enough in policy to build in a manner that would align with established
practice for running a Root CA.

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

Re: http subversion URLs should be discontinued in favor of https URLs

[Peter Wemm]

On 12/12/17 5:38 PM, Yuri wrote:

On 12/12/17 16:37, Peter Wemm wrote:
I think you're missing the point.  It is a sad reality that SSL/TLS 
corporate

(and ISP) MITM exists and is enforced on a larger scale than we'd like.  But
it is there, and when mandated/enforced you have to go through the MITM
appliance, or not connect at all.  Private CA's generally break those
appliances - an unfortunate FreeBSD user in this situation is cut off.  
How is

this better?



This is certainly better for users because it informs the user. Now he has 
a choice to use a special override key to use MITMed https anyway or 
refuse, vs. with http he is not informed.


You misunderstand the problem.

A well-behaving corporate with TLS MITM will *block* connections to the 
freebsd-ca signed services as they will fail it's validation.


The user is left with:
 * can't connect on 443 (proxy blocks failed validations), or
 * can't connect on 80 (because you don't like people having options).
.. which leads to stop using FreeBSD.

--
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: http subversion URLs should be discontinued in favor of https URLs

[Eugene Grosbein]

13.12.2017 7:13, Yuri пишет:
> On 12/12/17 11:56, Eugene Grosbein wrote:
>> https://wiki.squid-cache.org/Features/SslPeekAndSplice
>>
>> You either ignore MITM and proceed with connection anyway or have no 
>> connectivity via this channel at all.
> 
> 
> When the user sees that SSL/TLS is stripped, this isn't a vulnerability of 
> the protocol.

I never said it is vulnerability.

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

Re: http subversion URLs should be discontinued in favor of https URLs

[Michelle Sullivan]

Dag-Erling Smørgrav wrote:

Michelle Sullivan  writes:

Dag-Erling Smørgrav  writes:

Banks and financial institutions have whole teams working 24/7 [...]

No.

I was describing a fact, not opining or speculating.


So was I.


   I know these
people, I talk to them regularly and meet with them at industry events.


I literally cannot tell you what I do for/with them, it would be a 
breach of contract but if you look closely at some of the larger 
(non-European) banks, you might spot a clue or three.



Sorry to hear you're not part of the club — that doesn't mean the club
doesn't exist.


Absolutely true that.


I'm not going to say any more on this subject because it is so tempting 
for me to say something which could put me in a position that could call 
into question my employment.  Suffice it to say you might be right for 
Europe, but you should not dismiss my words about parts of the industry 
that you don't know about.


Regards,

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

Re: http subversion URLs should be discontinued in favor of https URLs

[Dag-Erling Smørgrav]

Michelle Sullivan  writes:
> Dag-Erling Smørgrav  writes:
> > Banks and financial institutions have whole teams working 24/7 [...]
> No.

I was describing a fact, not opining or speculating.  I know these
people, I talk to them regularly and meet with them at industry events.
Sorry to hear you're not part of the club — that doesn't mean the club
doesn't exist.

DES
-- 
Dag-Erling Smørgrav - d...@des.no
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: http subversion URLs should be discontinued in favor of https URLs

[Yuri]

On 12/12/17 16:37, Peter Wemm wrote:

I think you're missing the point.  It is a sad reality that SSL/TLS corporate
(and ISP) MITM exists and is enforced on a larger scale than we'd like.  But
it is there, and when mandated/enforced you have to go through the MITM
appliance, or not connect at all.  Private CA's generally break those
appliances - an unfortunate FreeBSD user in this situation is cut off.  How is
this better?



This is certainly better for users because it informs the user. Now he 
has a choice to use a special override key to use MITMed https anyway or 
refuse, vs. with http he is not informed.



Yuri


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

Re: http subversion URLs should be discontinued in favor of https URLs

[Peter Wemm]

On Tuesday, December 12, 2017 04:13:48 PM Yuri wrote:
> On 12/12/17 11:56, Eugene Grosbein wrote:
> > https://wiki.squid-cache.org/Features/SslPeekAndSplice
> > 
> > You either ignore MITM and proceed with connection anyway or have no
> > connectivity via this channel at all.
> When the user sees that SSL/TLS is stripped, this isn't a vulnerability
> of the protocol. User can make a choice to use such connection anyway.
> There are command line options like this for some commands, and the
> choice in the browser.
> 
> Compare this with https using compromised by government CA, when the
> user doesn't have any way of knowing about MITM. So https+private CA
> stands secure.

I think you're missing the point.  It is a sad reality that SSL/TLS corporate 
(and ISP) MITM exists and is enforced on a larger scale than we'd like.  But 
it is there, and when mandated/enforced you have to go through the MITM 
appliance, or not connect at all.  Private CA's generally break those 
appliances - an unfortunate FreeBSD user in this situation is cut off.  How is 
this better?

-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246

signature.asc
Description: This is a digitally signed message part.

Re: http subversion URLs should be discontinued in favor of https URLs

[Yuri]

On 12/12/17 11:56, Eugene Grosbein wrote:

https://wiki.squid-cache.org/Features/SslPeekAndSplice

You either ignore MITM and proceed with connection anyway or have no 
connectivity via this channel at all.



When the user sees that SSL/TLS is stripped, this isn't a vulnerability 
of the protocol. User can make a choice to use such connection anyway. 
There are command line options like this for some commands, and the 
choice in the browser.


Compare this with https using compromised by government CA, when the 
user doesn't have any way of knowing about MITM. So https+private CA 
stands secure.



Yuri

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

Re: http subversion URLs should be discontinued in favor of https URLs

[Eugene Grosbein]

On 13.12.2017 01:52, Yuri wrote:
> On 12/10/17 12:45, Eugene Grosbein wrote:
>> No, they don't. You get into MITM and then you have a choice: ignore and run 
>> your connection anyway
>> or have no connectivity at all (using this channel). Both are bad, so don't 
>> use such a channel from the beginning.
> 
> 
> No, MITM of https with the private CA isn't possible. Please provide 
> references if you believe that the opposite is true.

https://wiki.squid-cache.org/Features/SslPeekAndSplice

You either ignore MITM and proceed with connection anyway or have no 
connectivity via this channel at all.

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

Re: http subversion URLs should be discontinued in favor of https URLs

[Michelle Sullivan]

Dag-Erling Smørgrav wrote:

Michelle Sullivan  writes:

User gets an email saying his banking details are compromised, and to
update them now.  User clicks the link and gives banking details to
phishing site as well as having a keylogger and rootkit installed
during the process.  User has bank account hacked.  Where did the bank
go wrong?

Banks and financial institutions have whole teams working 24/7


Not out side of Europe (and those that do are not large.)


, usually
in cooperation with national authorities, to detect, investigate and
shut down phishing campaigns, and to warn customers (either directly or
through mass media) of particularly large or well-executed campaigns.


No.

In the EU and EEA, banks are liable for losses in excess of €150 unless
the customer acted “with intent or gross negligence”, but the definition
of “gross negligence” is fluid.  Legal precedent in Norway is to hold
the customer liable only if the email was “an obvious forgery”, for some
definition of “obvious”.

Maybe that will change stuff.


TL;DR: yes, banks are held liable for losses attributable to phishing.


No, and I can tell you I had a discussion with some un-named bank (but 
very well known, very very very well known) online security managers and 
I said to them, hold the users responsible for 419 type spams.  The 
response was a resounding 'no', and not because of regulation, but 
purely because they were worried about losing market share to other 
banks through bad publicity!


Source: I do this for a living (although not at a bank).

DES


So do I, have been in the business I am since 2000, and a lot of what I 
do and who for I can't even mention.  What I can tell you is I built 
SORBS, I still run SORBS and I still work closely with LEOs and Banks 
(amongst others) dealing with online security for the company that now 
owns SORBS.


This is getting way off-topic though.  The topic is about forcing the 
use of https over http in the name of 'securing' an inherently insecure 
and compromised network, in the name of privacy for a couple of people.  
Wrong solution, for the wrong reasons, svn over https is already 
available those people that believe it gives security should use it and 
get out of other peoples business.  If they really want to make an 
impact on the perceived problem they should target the malicious actors 
and the use of Tor as a pseudo secure platform (ie the few that would 
use http over Tor for downloading source that don't know the dangers 
should probably learn or not use Tor in the first place!)


Regards,

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

Re: http subversion URLs should be discontinued in favor of https URLs

[Yuri]

On 12/10/17 12:45, Eugene Grosbein wrote:

No, they don't. You get into MITM and then you have a choice: ignore and run 
your connection anyway
or have no connectivity at all (using this channel). Both are bad, so don't use 
such a channel from the beginning.



No, MITM of https with the private CA isn't possible. Please provide 
references if you believe that the opposite is true.



Yuri

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

Re: http subversion URLs should be discontinued in favor of https URLs

[Matthew Finkel]

On Tue, Dec 12, 2017 at 06:22:19PM +0100, Jan Bramkamp wrote:
> 
> On 12.12.17 15:28, Poul-Henning Kamp wrote:
> > 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.
> > 
> > > 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.
> 
> How about an uncompressed tarball signed with signify? It could be
> replicated with rsync (or zsync) and getting security patches wouldn't
> require lots of network bandwidth.

Portsnap already provides signed snapshots of the tree from mirrors. The
main problem is checking out the full tree as-is from the subversion
servers.

> 
> I still prefer to encrypt every transfer with PFS only protocols, but even
> with transport encryption in place content authentication is still valuable
> because it allows the use of caching proxies.
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: http subversion URLs should be discontinued in favor of https URLs

[Bakul Shah]

On Tue, 12 Dec 2017 14:28:08 + "Poul-Henning Kamp"  
wrote:
> 
> 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.

Sort of a public ledger. I have a vague memory of some project
*publishing* a crypto fingerprint of a collection of documents
in a well-known newspaper  I think it was this one:

https://www.technologyreview.com/s/402961/fingerprinting-your-files/

Computing hashes of hashes is also the basis of a secure
timestamp service invented by Stuart Haber and Scott
Stornetta while the two were at Bellcore in 1990. The
service, called Surety, makes it possible to generate a
cryptographically secure and unforgeable proof that a
given document, photograph, or other file existed at a
particular time on a particular date and that it hasnt
been changed since.

The Surety technique works by computing a hash tree based
on the hash codes of every document being time-stamped.
The root of the tree is then published in a well-known
locationit could, for example, be printed in a classified
advertisement in the New York Times. You can prove that
your document existed on the day in question by showing
that your documents fingerprint was needed to generate the
fingerprint-of-fingerprints that appeared in the
newspaper.

Nowadays can you even trust NYT?!
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: http subversion URLs should be discontinued in favor of https URLs

[Jan Bramkamp]

On 12.12.17 15:28, Poul-Henning Kamp wrote:

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.


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.


How about an uncompressed tarball signed with signify? It could be 
replicated with rsync (or zsync) and getting security patches wouldn't 
require lots of network bandwidth.


I still prefer to encrypt every transfer with PFS only protocols, but 
even with transport encryption in place content authentication is still 
valuable because it allows the use of caching proxies.

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

Re: http subversion URLs should be discontinued in favor of https URLs

[Poul-Henning Kamp]

In message <864lovhpvr@desk.des.no>, =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= w
rites:

>Let me rephrase: it's not just the source of the key or certificate, but
>the path from that source to you.  There is *always* some level of blind
>trust, and all your suggestion does is move it from one place to
>another.

That is correct, and I don't see any problem in applying the usual
level of trust we use in this project to that cert.

For instance, our core team elections are usually run by some
Norvegian dude who very few committers have actually met in
real life.

But the committers seem to be willing to entrust that task to him
because those of us who have met this Norvegian dude agree that his
zealous pedantry is well suited to running our elections :-)

>The bottom line is, once again, that key distribution is hard, and that
>you shouldn't make infosec decisions without having at least a vague
>outline of a threat model.

Absolutely.

But just to sum up:  We are talking about anonymous checkouts of
our source tree, and as far as my analysis goes, we are long past
this point:

https://www.youtube.com/watch?v=X0bWWtTIPlg

Poul-Henning

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: http subversion URLs should be discontinued in favor of https URLs

[Dag-Erling Smørgrav]

"Poul-Henning Kamp"  writes:
> "Dag-Erling Smørgrav"  writes:
> > Your suggestion does not remove implicit and possibly misplaced
> > trust, it just moves it from one place to another.  Instead of
> > trusting a certificate authority and DNS, you trust the source of
> > the public key, and probably also DNS.  As always, it boils down to
> > a) key distribution is hard and b) what's your threat model?
> I don't think I agree with any of that ?
>
> With respect to authenticity of the FreeBSD SVN repo I cannot imagine
> anybody else being even one percent as qualified and trustworth as the
> FreeBSD projects own core-team.  [...]

Let me rephrase: it's not just the source of the key or certificate, but
the path from that source to you.  There is *always* some level of blind
trust, and all your suggestion does is move it from one place to
another.  You trust the certificate because you trust the PGP key that
was used to sign it, but why do you trust the key?  Did someone you know
personally vouch for it?  Do you trust them?  Were they present when the
key was generated, or do they trust it because someone *they* trust told
them it was genuine?  Does your trust in whomever gave you the key
translate to those they trust?  Is there a bottom to this pit?

The bottom line is, once again, that key distribution is hard, and that
you shouldn't make infosec decisions without having at least a vague
outline of a threat model.

DES
-- 
Dag-Erling Smørgrav - d...@des.no
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: http subversion URLs should be discontinued in favor of https URLs

[Poul-Henning Kamp]

In message <6fff232c-65c0-34bc-a950-0e79eda02...@denninger.net>, Karl Denninger
 writes:

>> 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.

It sure does, but knowing crypto-code and knowing the projects
decision making process about such things, I see neither adding that
to svn nor replacing svn as feasible this side of 2020.

>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.

+1

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: http subversion URLs should be discontinued in favor of https URLs

[Karl Denninger]

On 12/12/2017 08:28, Poul-Henning Kamp wrote:
> 
> In message , 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
k...@denninger.net 
/The Market Ticker/
/[S/MIME encrypted email preferred]/


smime.p7s
Description: S/MIME Cryptographic Signature

Re: http subversion URLs should be discontinued in favor of https URLs

[Poul-Henning Kamp]

In message , 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 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.

>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.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: http subversion URLs should be discontinued in favor of https URLs

[Karl Denninger]

On 12/12/2017 06:59, Poul-Henning Kamp wrote:
> 
> In message <86d13kgnfh@desk.des.no>, =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= 
> w
> rites:
>> "Poul-Henning Kamp"  writes:
>>> The only realistic way for the FreeBSD project to implement end-to-end
>>> trust, is HTTPS with a self-signed cert, distributed and verified
>>> using the projects PGP-trust-mesh and strong social network.
>> Your suggestion does not remove implicit and possibly misplaced trust,
>> it just moves it from one place to another.  Instead of trusting a
>> certificate authority and DNS, you trust the source of the public key,
>> and probably also DNS.  As always, it boils down to a) key distribution
>> is hard and b) what's your threat model?
> I don't think I agree with any of that ?
>
> With respect to authenticity of the FreeBSD SVN repo I cannot
> imagine anybody else being even one percent as qualified and
> trustworth as the FreeBSD projects own core-team.
>
> In particular I would never trust any "In the CA-racket for the
> money" organization to do so.
>
> If you are worried that the FreeBSD project "staff" cannot
> handle a root-cert competently, then the exposure is no
> smaller or larger than if it was a CA-signed cert they fumbled.
>
> Trusting DNS doesn't apply it if the project root-cert was
> stored on my local machine after I used my best judgement of PGP
> signatures to conclude that it was authentic.
>
> And I don't really see distribution of this particular key being
> difficult at all:  We already PGP sign release checksums for
> authenticity and it the FreeBSD root-cert is just another file to
> get same treatment.
>
> Poul-Henning
Agreed.

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 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.*

Attempting to "overload" TLS with this responsibility now requires that
the project take operational and security responsibility for the
integrity of any *mirror* of said code, which is IMHO flatly
unreasonable and thus is simply not going to happen.  Otherwise you can
have all the assurance you want that the bits you get are the bits that
were on the disk at the other end, but no assurance at all that the bits
on the disk *are the same as the bits on the FreeBSD project's machines!*

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)

-- 
Karl Denninger
k...@denninger.net 
/The Market Ticker/
/[S/MIME encrypted email preferred]/


smime.p7s
Description: S/MIME Cryptographic Signature

Re: http subversion URLs should be discontinued in favor of https URLs

[Poul-Henning Kamp]

In message <86d13kgnfh@desk.des.no>, =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= w
rites:
>"Poul-Henning Kamp"  writes:
>> The only realistic way for the FreeBSD project to implement end-to-end
>> trust, is HTTPS with a self-signed cert, distributed and verified
>> using the projects PGP-trust-mesh and strong social network.
>
>Your suggestion does not remove implicit and possibly misplaced trust,
>it just moves it from one place to another.  Instead of trusting a
>certificate authority and DNS, you trust the source of the public key,
>and probably also DNS.  As always, it boils down to a) key distribution
>is hard and b) what's your threat model?

I don't think I agree with any of that ?

With respect to authenticity of the FreeBSD SVN repo I cannot
imagine anybody else being even one percent as qualified and
trustworth as the FreeBSD projects own core-team.

In particular I would never trust any "In the CA-racket for the
money" organization to do so.

If you are worried that the FreeBSD project "staff" cannot
handle a root-cert competently, then the exposure is no
smaller or larger than if it was a CA-signed cert they fumbled.

Trusting DNS doesn't apply it if the project root-cert was
stored on my local machine after I used my best judgement of PGP
signatures to conclude that it was authentic.

And I don't really see distribution of this particular key being
difficult at all:  We already PGP sign release checksums for
authenticity and it the FreeBSD root-cert is just another file to
get same treatment.

Poul-Henning

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: http subversion URLs should be discontinued in favor of https URLs

[Dag-Erling Smørgrav]

"Poul-Henning Kamp"  writes:
> The only realistic way for the FreeBSD project to implement end-to-end
> trust, is HTTPS with a self-signed cert, distributed and verified
> using the projects PGP-trust-mesh and strong social network.

Your suggestion does not remove implicit and possibly misplaced trust,
it just moves it from one place to another.  Instead of trusting a
certificate authority and DNS, you trust the source of the public key,
and probably also DNS.  As always, it boils down to a) key distribution
is hard and b) what's your threat model?

DES
-- 
Dag-Erling Smørgrav - d...@des.no
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: http subversion URLs should be discontinued in favor of https URLs

[Dag-Erling Smørgrav]

Michelle Sullivan  writes:
> User gets an email saying his banking details are compromised, and to
> update them now.  User clicks the link and gives banking details to
> phishing site as well as having a keylogger and rootkit installed
> during the process.  User has bank account hacked.  Where did the bank
> go wrong?

Banks and financial institutions have whole teams working 24/7, usually
in cooperation with national authorities, to detect, investigate and
shut down phishing campaigns, and to warn customers (either directly or
through mass media) of particularly large or well-executed campaigns.
In the EU and EEA, banks are liable for losses in excess of €150 unless
the customer acted “with intent or gross negligence”, but the definition
of “gross negligence” is fluid.  Legal precedent in Norway is to hold
the customer liable only if the email was “an obvious forgery”, for some
definition of “obvious”.

TL;DR: yes, banks are held liable for losses attributable to phishing.

Source: I do this for a living (although not at a bank).

DES
-- 
Dag-Erling Smørgrav - d...@des.no
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: http subversion URLs should be discontinued in favor of https URLs

[Matthew Finkel]

On Mon, Dec 11, 2017 at 12:18:27PM -0600, Karl Denninger wrote:
> 
> On 12/11/2017 12:08, Matthew Finkel wrote:
> > On Mon, Dec 11, 2017 at 05:34:48PM +0100, WhiteWinterWolf wrote:
> >
> >> This is a reason why I personally like software and system updates to be
> >> served through HTTP instead of HTTPS. You don't need to fetch the same
> >> update for each environment each time from the remote vendor's system,
> >> you just need them to be somehow signed by him to ensure their 
> >> authenticity.
> > That's fine, you should have this ability if you understand the
> > risks/consequences, but this should not be forced on other users.
> It is NOT forced.  You can use SVN now over http OR https.

Yes, sorry, my mistake. I saw portsnap only uses http (with signed
snapshots from mirrors), and I misread the website documentation (where
it does specify https for `svn checkout https://[...]`). And no, I
didn't look at the ticket first.

> >> This was just to give an example of why one would prefer to use HTTP
> >> over HTTPS, and how as highlighted by Karl Denninger a system which does
> >> too much may actually be harmful.
> > I disagree with this. The importance of message confidentiality doesn't
> > magically disappear because someone is retrieving public information.
> Again, let's target the actual problem.
> 
> Advocating the FORCING of https is IMHO utterly ridiculous for the
> reasons I pointed out.

I understand why some people believe a resource should be available over
http. It makes life easier in many situations. However, Yuri is correct,
serving svn with http over the Internet is dangerous and should be
discontinued. It is too easy for someone to make a mistake and checkout
the ports repo over http (if they type it by hand instead of copying and
pasting it from the handbook). That being said, if users can checkout
the svn repos over an onion service, then the threat of tampering with
the traffic in-transit is mitigated.

The simple and undeniable fact of this matter is users make mistakes. As
it was already mentioned multiple times, the recent trend by
organizations on this topic is disabling access over plaintext HTTP
entirely. It's obvious FreeBSD are unwilling to follow this pattern
based on the presumption "That isn't tenable, far too many people around
the world have limited internet access as it is."[0]

Sure.

[0] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224097#c3

> 
> Today you CAN use https with svn if you wish.  You are not *forced* to. 
> There are good reasons not to, including caching.  The problem with not
> knowing if what you got is authentic and not tampered with is simply not
> resolved by forcing https; it's an out-of-scope hack that fails to
> target the actual issue.

Correct. TLS accomplishes a different goal, it does not provide any
guarantee about the whether the data is authentic. It simply provides
assurance the data was not tampered in transit and it significantly
increases the probability none of the intermediate parties learned what
data was transmitted.

> 
> A forced election of something that doesn't actually solve the problem
> is IMHO a political argument rather than a technical one.  The issue of
> potentially-tampered-with source code not only can't be dealt with
> correctly through the use of https (at least not with the public CA
> infrastructure that "everyone" relies on for "pedestrian" https) there
> ARE other means of dealing with it correctly that do not require using
> https.

Yes. On the other hand, code authenticity isn't the reason software
projects use TLS. I fully agree another mechanism should be put in place
for this. Whether hacking a Merkle Hash Tree on top of SVN is the correct
decision is an entirely different discussion.

> 
> That's where attention should be focused.
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: http subversion URLs should be discontinued in favor of https URLs

[Matthew Finkel]

On Mon, Dec 11, 2017 at 09:05:58PM +, Poul-Henning Kamp wrote:
> 
> In message <20171211182031.jhgansyyw7xrk4il@localhost>, Matthew Finkel writes:
> 
> >Most of the relays are in Europe now [...]
> 
> Thank goodness nobody shady can rent cloud servers in Europe!

I'm glad you have a sense of humor.
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: http subversion URLs should be discontinued in favor of https URLs

[Yuri]

On 12/11/17 14:40, Yonas Yanfa wrote:
I prefer HTTPS over HTTP as well, but wouldn't switching over to git 
and using signed commits be even more secure than using HTTPS? 



So far, nobody pointed out even one security flaw of using https 
combined with the private CA. So no, they appear to be equally secure, 
with https approach having the advantage of being able to work on the 
same infrastructure in virtually the same way.



Yuri

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

Re: http subversion URLs should be discontinued in favor of https URLs

[Yonas Yanfa]

On 12/11/2017 16:29, Jamie Landeg-Jones wrote:

Matthew Finkel  wrote:


Why doesn't everyone have that option? Why is broadcasting a users information
across the internet forced upon them? Shouldn't they have a choice?

They do! HTTPS already exists!

This thread is about removing HTTP and forcing HTTPS - "Why should
HTTPS be forced upon them? Shouldn't they have a choice?"

:-)

  | 21:16 (4) "/tmp" root@lapcat# svn export 
https://svn.freebsd.org/base/stable/11/usr.bin/fortune
  | Afortune
  | Afortune/datfiles
  |
  | [ ... ]
  |
  | Afortune/tools/Troff.sed
  | Exported revision 326782.

Voila! A https delivery of "fortune" ! (Confirmed via tcpdump not to be
using fallback HTTP)

cheers!


Yuri,

I prefer HTTPS over HTTP as well, but wouldn't switching over to git and 
using signed commits be even more secure than using HTTPS?


Yonas

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

Re: http subversion URLs should be discontinued in favor of https URLs

[Jamie Landeg-Jones]

Matthew Finkel  wrote:

> Why doesn't everyone have that option? Why is broadcasting a users information
> across the internet forced upon them? Shouldn't they have a choice?

They do! HTTPS already exists!

This thread is about removing HTTP and forcing HTTPS - "Why should
HTTPS be forced upon them? Shouldn't they have a choice?"

:-)

 | 21:16 (4) "/tmp" root@lapcat# svn export 
https://svn.freebsd.org/base/stable/11/usr.bin/fortune
 | Afortune
 | Afortune/datfiles
 |
 | [ ... ]
 |
 | Afortune/tools/Troff.sed
 | Exported revision 326782.

Voila! A https delivery of "fortune" ! (Confirmed via tcpdump not to be
using fallback HTTP)

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

Re: http subversion URLs should be discontinued in favor of https URLs

[Jamie Landeg-Jones]

John-Mark Gurney  wrote:

> So you're fine w/ all the Comcast users having to switch ISPs?  Because
> Comcast modifies traffic.  So you're now saying that if you use FreeBSD
> you can't use Comcast as your ISP?

... or they could use HTTPS, which exists.

This thread started with the proposal to remove HTTP, nothing to do with 
disabling already existing HTTPS solutions.

Cheers, J.

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

Re: http subversion URLs should be discontinued in favor of https URLs

[Roger Marquis]

Karl Denninger wrote:

Advocating the FORCING of https is IMHO utterly ridiculous for the
reasons I pointed out.


This is an important point.  Given the differences of opinion noted here
there is no good reason not to allow sites to sync over the protocol of
their choosing.  Of course signed datasets would be excellent, as would
verifiable builds, but (also IMO) not good enough to justify forcing of
non-encrypted updates.


The issue of potentially-tampered-with source code not only can't be dealt
with correctly through the use of https (at least not with the public CA
infrastructure that "everyone" relies on for "pedestrian" https) there ARE
other means of dealing with it correctly that do not require using https.
That's where attention should be focused.


Would have to disagree with this assertion, at least until it can be
demonstrated that an alternative signature presharing mechanism would be
more secure (than the CA maintained by EFF/LetsEncrypt at least).

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

Re: http subversion URLs should be discontinued in favor of https URLs

[Matthew Finkel]

On Sun, Dec 10, 2017 at 07:57:14PM +, Poul-Henning Kamp wrote:
> 
> In message <898df78d-c0b1-9e9f-0630-2665c3939...@rawbw.com>, Yuri writes:
> 
> >3. The user updated the sources through Tor and got hacked.
> >
> >Where did this user go wrong, or where has he been irresponsible?
> 
> He trusted Tor?
> 
> In 2006 Steven Murdochs "Hot or Not" work in TCP timers revealed
> that a LOT of the Tor network is on a longitude compatible with a
> "Bandit of The Beltway" location.

Are you really referencing a paper from 11 years ago specifically about
a hidden service confirmation attack? This is not within Tor's threat
model. Yes, it is a real attack, and yes, this could and should be
prevented, but this says absolutely nothing about the security or
"trustworthiness" of the Tor network or the protection it provides 99%
of all users.

> 
> If you still, elleven years later, seriously belive that Tor is
> trustworthy, you shouldn't be allowed near any kind of security
> decision.

*head scratch*

Most of the relays are in Europe now, just FYI. Tor is not perfect, but
it offers by-far a better method of connecting two machines than using
the Internet alone.

> 
> -- 
> Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
> p...@freebsd.org | TCP/IP since RFC 956
> FreeBSD committer   | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
> ___
> freebsd-security@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: http subversion URLs should be discontinued in favor of https URLs

[Karl Denninger]

On 12/11/2017 12:08, Matthew Finkel wrote:
> On Mon, Dec 11, 2017 at 05:34:48PM +0100, WhiteWinterWolf wrote:
>
>> This is a reason why I personally like software and system updates to be
>> served through HTTP instead of HTTPS. You don't need to fetch the same
>> update for each environment each time from the remote vendor's system,
>> you just need them to be somehow signed by him to ensure their authenticity.
> That's fine, you should have this ability if you understand the
> risks/consequences, but this should not be forced on other users.
It is NOT forced.  You can use SVN now over http OR https.
>> This was just to give an example of why one would prefer to use HTTP
>> over HTTPS, and how as highlighted by Karl Denninger a system which does
>> too much may actually be harmful.
> I disagree with this. The importance of message confidentiality doesn't
> magically disappear because someone is retrieving public information.
Again, let's target the actual problem.

Advocating the FORCING of https is IMHO utterly ridiculous for the
reasons I pointed out.

Today you CAN use https with svn if you wish.  You are not *forced* to. 
There are good reasons not to, including caching.  The problem with not
knowing if what you got is authentic and not tampered with is simply not
resolved by forcing https; it's an out-of-scope hack that fails to
target the actual issue.

A forced election of something that doesn't actually solve the problem
is IMHO a political argument rather than a technical one.  The issue of
potentially-tampered-with source code not only can't be dealt with
correctly through the use of https (at least not with the public CA
infrastructure that "everyone" relies on for "pedestrian" https) there
ARE other means of dealing with it correctly that do not require using
https.

That's where attention should be focused.

-- 
Karl Denninger
k...@denninger.net 
/The Market Ticker/
/[S/MIME encrypted email preferred]/


smime.p7s
Description: S/MIME Cryptographic Signature

Re: http subversion URLs should be discontinued in favor of https URLs

[Matthew Finkel]

On Mon, Dec 11, 2017 at 05:34:48PM +0100, WhiteWinterWolf wrote:
> Hi,
> 
> Le 11/12/2017 à 16:08, Christian Weisgerber a écrit :
> > Do users actually exist who have access to http but not to https?
> 
> I don't know about users, but caching is not possible anymore as soon
> you use end-to-end HTTPS.

Why must caching be at a MiTM? Why not simply have a subversion mirror
on the same network? It is utterly unacceptable that "caching" is a
reason why encryption is not considered as an option.

> 
> This is a reason why I personally like software and system updates to be
> served through HTTP instead of HTTPS. You don't need to fetch the same
> update for each environment each time from the remote vendor's system,
> you just need them to be somehow signed by him to ensure their authenticity.

That's fine, you should have this ability if you understand the
risks/consequences, but this should not be forced on other users.

> 
> This was just to give an example of why one would prefer to use HTTP
> over HTTPS, and how as highlighted by Karl Denninger a system which does
> too much may actually be harmful.

I disagree with this. The importance of message confidentiality doesn't
magically disappear because someone is retrieving public information.
The intermediate ISPs do not have the privilege of knowing what an end
user is sending or receiving, we should not give them this information.
They are simply passing along those packets based on aggregated route
summaries, but no one should blindly trust these companies. The Internet
is not a benevolent series of tubes - intentionally endangering users by
not providing a mechanism for cryptographic authentication and checking
data integrity is absolutely unacceptable. Everyone should have the
option of hiding from intermediate parties what information they are
retrieiving, verifying the information they received was not tampered
in-transit, and verifying the information they received was not tampered
on-disk prior to transmission.

I also advocate for preventing the tracking of user activities, but at a
minimum please provide message authentication and message
confidentiality.

While I find this entire discussion ridiculous, because I can't believe
a software project is actually debating the necessity of secure code
transmission, removing the option of an unauthenticated connection to
the subversion server is not necessary, but imposing this on every user
is completely irresponsible.

> 
> When you need signature, then apply signature, don't add encryption,
> tunneling, dynamic cipher suites negotiation, session keys exchange and
> so on as overhead.

Yes, TLS is a bloated protocal and most of it is not necessary, but are
you saying the additional ~100 millisecond latency with its ~5KB
handshake is too much overhead for downloading subversion updates? We
are talking about 7 additional packets. This is not too much, even on a
terrible Internet connection with high packet loss.

TLS does not authenticate the revisions a user downloads, it's
remarkable subversion still does not provide this ability after 16
years.

> Regards,
> Simon.
> 
> -- 
> WhiteWinterWolf
> https://www.whitewinterwolf.com
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: http subversion URLs should be discontinued in favor of https URLs

[WhiteWinterWolf]

Hi,

Le 11/12/2017 à 16:08, Christian Weisgerber a écrit :
> Do users actually exist who have access to http but not to https?

I don't know about users, but caching is not possible anymore as soon
you use end-to-end HTTPS.

This is a reason why I personally like software and system updates to be
served through HTTP instead of HTTPS. You don't need to fetch the same
update for each environment each time from the remote vendor's system,
you just need them to be somehow signed by him to ensure their authenticity.

This was just to give an example of why one would prefer to use HTTP
over HTTPS, and how as highlighted by Karl Denninger a system which does
too much may actually be harmful.

When you need signature, then apply signature, don't add encryption,
tunneling, dynamic cipher suites negotiation, session keys exchange and
so on as overhead.

Regards,
Simon.

-- 
WhiteWinterWolf
https://www.whitewinterwolf.com
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: http subversion URLs should be discontinued in favor of https URLs

[Igor Mozolevsky]

On 11 December 2017 at 16:06, Karl Denninger  wrote:



SVN's shortcoming is that it does nothing for [integrity] on an inherent
> basis
> and this debate is thus about trying to use a tool that allegedly does
> three things when we really only need one of them.
>



This is precisely why I suggested that something along the lines of a
Merkle Tree of signed hashes over the revisions would provide adequate
integrity, and I am guessing it'd be pretty straight forward to implement
with SVN hooks (maybe?). I just don't have the time to look into it in any
details.


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

Re: http subversion URLs should be discontinued in favor of https URLs

[Karl Denninger]

On 12/11/2017 09:16, Shawn Webb wrote:
> On Mon, Dec 11, 2017 at 03:08:37PM -, Christian Weisgerber wrote:
>> On 2017-12-08, Luke Crooks  wrote:
>>
>>> The pull request was rejected for a valid reason, offering http allows
>>> users with limited network access chance to clone or download freebsd where
>>> https is not possible.
>> Do users actually exist who have access to http but not to https?
>> Or is this a myth?  And how do these users access popular sites
>> like Wikipedia, or www.FreeBSD.org for that matter?
> In an effort to enforce encrypted comms, my network is the inverse:
> TCP:80 is disallowed, but TCP:443 is accepted.
>
> Thanks,
Wading back into this; it may be worth one half of 2 bits from other's
points of view

IMO there are three issues and we're conflating them/.  This is
unfortunate because only one of them matters.

/Https allegedly provides three things:
1. Attestation (you're talking to who you think you are)
2. Data integrity (the data has not been tampered with)
3. Privacy during transport (nobody but the receiving party can observe
the payload except on the sending and terminal ends)

#2 in https comes about because if #1 is true then the payload will not
decode if someone tampers with it or the certificate in use, /provided
/the correct options are enforced.

The problem is that if #1 is false then both #2 and #3 are ALSO false,
because if I can tamper with attestation then I can MITM the data
(insert discussion/debate/whatever on the existing CA structure, etc.
which is really the never-ending debate on key management, distribution
and the vouching process in any given certificate management design) 
This leads to all sorts of other issues (like intentional MITM behavior
via wildcard certs and overrides on certificate checking by corporate IT
departments, possibly ISPs, user anti-virus software, compromise of a CA
by state actors or hackers, etc.)  The premise of https is very pretty
but the implementation -- not so much. Nonetheless a whole lot of
commerce and such depends on it, because all three are required for
commerce so imperfect beats nothing.

But in the context of code distribution I care not about #3.  I care
/very much /that /the code is untampered with/ (#2)/, /but note that I
really _*don't*_ care about #3 at all because the code is /intentionally
published to the public at large/ and I don't care _*much*_ about #1 (if
someone mirrors the source /exactly /then whether I get it from
FreeBSD's server or some interloper doesn't really matter either.)

SVN's shortcoming is that it does nothing for #2 on an inherent basis
and this debate is thus about trying to use a tool that allegedly does
three things when we really only need one of them.

Maybe it's time to move toward something that can for source
distribution to the public (e.g. Git) instead of trying to abuse
something that we know can't actually meet the criteria required?

Just sayin'.

-- 
Karl Denninger
k...@denninger.net 
/The Market Ticker/
/[S/MIME encrypted email preferred]/


smime.p7s
Description: S/MIME Cryptographic Signature

Re: http subversion URLs should be discontinued in favor of https URLs

[Shawn Webb]

On Mon, Dec 11, 2017 at 03:08:37PM -, Christian Weisgerber wrote:
> On 2017-12-08, Luke Crooks  wrote:
> 
> > The pull request was rejected for a valid reason, offering http allows
> > users with limited network access chance to clone or download freebsd where
> > https is not possible.
> 
> Do users actually exist who have access to http but not to https?
> Or is this a myth?  And how do these users access popular sites
> like Wikipedia, or www.FreeBSD.org for that matter?

In an effort to enforce encrypted comms, my network is the inverse:
TCP:80 is disallowed, but TCP:443 is accepted.

Thanks,

-- 
Shawn Webb
Cofounder and Security Engineer
HardenedBSD

GPG Key ID:  0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE


signature.asc
Description: PGP signature

Re: http subversion URLs should be discontinued in favor of https URLs

[Christian Weisgerber]

On 2017-12-08, Luke Crooks  wrote:

> The pull request was rejected for a valid reason, offering http allows
> users with limited network access chance to clone or download freebsd where
> https is not possible.

Do users actually exist who have access to http but not to https?
Or is this a myth?  And how do these users access popular sites
like Wikipedia, or www.FreeBSD.org for that matter?

This is also of interest for the choice of master sites in ports.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: http subversion URLs should be discontinued in favor of https URLs

[Michelle Sullivan]

John-Mark Gurney wrote:

Michelle Sullivan wrote this message on Fri, Dec 08, 2017 at 21:29 +1100:

Sorry you want to ensure a secure (trusted) connection you do it
yourself.  You go through other nodes (switches and routers of the

So you're fine w/ all the Comcast users having to switch ISPs?  Because
Comcast modifies traffic.


Sure, my ISP in Australia modifies some traffic (how much I don't know 
because I haven't looked deeply) first detection of it I setup 
mitigation to secure my connection from tampering... where I care about it.


In my case they disabled https access so they could MITM... All my 
http(s) traffic now goes through a proxy, and all my network traffic now 
exits over a VPN connection to my network in a DC which hosts the top of 
my proxy server chain.



  So you're now saying that if you use FreeBSD
you can't use Comcast as your ISP?


No, I'm saying if you can't trust ${ISP} to give you your FreeBSD source 
untampered with, you should not use ${ISP} as your ISP... don't give a 
t*** who ${ISP} is, if you can't trust it, don't use it or mitigate your 
trust issues by doing like me.


This argument is circular and pointless, if ${User} is downloading and 
compiling FreeBSD from source there is a pretty good chance they know a 
little more about Tor than 'I heard this app will allow me anonymity'... 
Seriously, you want anonymity and safety I have a device that I'll send 
you for free... Its lightweight and simple, it consists of two metal 
blades with a pivot in the middle.


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

Re: http subversion URLs should be discontinued in favor of https URLs

[Poul-Henning Kamp]

In message <20171210225326.gk5...@funkthat.com>, John-Mark Gurney writes:

>IMO, all security needs to be node-to-node. 

There's nothing "IMO" about that.

The end-to-end principle became a bed-rock foundation of all rational
networking with "End to End Arguments in System Design" in 1981.

http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf

The only realistic way for the FreeBSD project to implement end-to-end
trust, is HTTPS with a self-signed cert, distributed and verified
using the projects PGP-trust-mesh and strong social network.

Anything else is just pretend-security today.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: http subversion URLs should be discontinued in favor of https URLs

[Michelle Sullivan]

John-Mark Gurney wrote:

Igor Mozolevsky wrote this message on Sun, Dec 10, 2017 at 19:17 +:

On 10 December 2017 at 19:02, John-Mark Gurney  wrote:



So, you require an exploit in the wild before you'll patch?

No, I'm saying it's not a realistic threat model! If the threat is the
integrity of the source code in transit, then it'd be way cheaper and way
more reasonable to implement a Merkle Tree-like verification with each
revision.

Then you should be fine w/ http for banking sites, since it's not realistic
that your ISP will MITM your connection to steal money from you, right?
I don't know of a single instance of an ISP MITM'ing banking transactions
to steal money.


Invalid analogy... You probably shouldn't go there... so I will.

I have in the past (long time ago - well past that statute of 
limitations - so can share now) compromised an FTP server on a certain 
European ISPs network, on there I put a password sniffer looking for a 
very specific user/connection/password combination... 4 hours it took to 
get the password I then had "root" across their entire network and in 
particular to their IRC server... needless to say I have grown up since 
those days.  However, at the time there was very little online banking, 
and all the banking I knew about was pretty much read only (checking 
balances, authorising payments to pre-existing arrangements etc)... but 
using this 'well you might as well use HTTP' would have left me with the 
opportunity to make a lot of illegal money real quick if you apply it now.


Here's a tip, you come to my street and find my open wifi, I'll 
compromise your arse (just the same as these hypothetical 'malicious Tor 
node operators') you want a secure connection, one that won't leave you 
with a hacked android device, don't use my open wifi network.  Come and 
ask me to use my secure network, or use another network.


Michelle


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

Re: http subversion URLs should be discontinued in favor of https URLs

[John-Mark Gurney]

Michelle Sullivan wrote this message on Mon, Dec 11, 2017 at 09:41 +1100:
> Yuri wrote:
> > On 12/10/17 10:15, Igor Mozolevsky wrote:
> >> They are not "hypothetical characters," they are invented characters 
> >> that
> >> are used in a threat model. But that's reframing the problem- a
> >> hypothetical threat model is very different to a real threat model.
> >
> >
> > This is a very real threat model. There are a lot of malicious Tor 
> > exit node operators, and a lot of FreeBSD users update their system 
> > over subversion. The only thing that the Tor node operator needs to do 
> > is to detect relevant requests and serve malware.
> >
> > How is this not real?
> 
> Sounds to me the proper solution is stop using Tor.
> 
> If you can't trust the network (wire) no matter what you do you can't 
> guarantee safety.

IMO, all security needs to be node-to-node.  It needs to be assumed
that the network is compromised.  Be it public wifi, tor, or malicious
actor rerouting traffic via BGP spoofing, node-to-node protection is
the answer to all of those.

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 assess
what may have been compromised.

-- 
  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
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: http subversion URLs should be discontinued in favor of https URLs

[Michelle Sullivan]

Yuri wrote:

On 12/10/17 11:36, Igor Mozolevsky wrote:

If I give my bank card and PIN to someone who I don't trust, I can't
complain that my bank doesn't take adequate precautions if that person
drains my bank account! You choose to go down a route that*you* know is
compromised!



1. The user has set up the subversion source trees based on the 
*current advice* here for anonymous checkout: 
https://wiki.freebsd.org/PortsSubversionPrimer



% svn co http://svn.freebsd.org/ports/head /usr/ports


2. The user heard that Tor improves his anonymity, and decided to use it.

3. The user updated the sources through Tor and got hacked.

Where did this user go wrong, or where has he been irresponsible?



User gets an email saying his banking details are compromised, and to 
update them now.


User clicks the link and gives banking details to phishing site as well 
as having a keylogger and rootkit installed during the process.


User has bank account hacked.

Where did the bank go wrong?

Bank installs secondary security to prevent phishing/user realises the 
site is phishing and puts in false details or aborts the input...  
Keylogger is still on their system though because that was installed on 
the first click before the page was updated because of a compromised 
Microsoft code signing certificate...


Where did the bank or the user go wrong?

Maybe instead, user takes their phone into the local Maccas and uses the 
hotspot there, as part of the sign-in they get a compromised app from a 
local hacker that has been stalking the hotspot...  Ding ding ding we 
have a winner... can't trust the network, just like the Tor case...


etc

etc

etc

Michelle

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

Re: http subversion URLs should be discontinued in favor of https URLs

[Michelle Sullivan]

Yuri wrote:

On 12/10/17 10:15, Igor Mozolevsky wrote:
They are not "hypothetical characters," they are invented characters 
that

are used in a threat model. But that's reframing the problem- a
hypothetical threat model is very different to a real threat model.



This is a very real threat model. There are a lot of malicious Tor 
exit node operators, and a lot of FreeBSD users update their system 
over subversion. The only thing that the Tor node operator needs to do 
is to detect relevant requests and serve malware.


How is this not real?


Sounds to me the proper solution is stop using Tor.

If you can't trust the network (wire) no matter what you do you can't 
guarantee safety.


Seriously if there are "a lot of malicious Tor exit node operators" the 
simple answer is stop using Tor.


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

Re: http subversion URLs should be discontinued in favor of https URLs

[Eugene Grosbein]

11.12.2017 3:54, Yuri wrote:

>>> Modern encryption protocols allow you to send traffic over insecure 
>>> networks and still maintain your security and privacy, so why not?
>> No, they don't. You get into MITM and then you have a choice: ignore and run 
>> your connection anyway
>> or have no connectivity at all (using this channel). Both are bad, so don't 
>> use such a channel from the beginning.
> 
> There's no MITMing with https unless you are a state actor. There are very 
> few state actors, they are special case.
> Regular hackers can't MITM https, but can MITM http.

You either have no idea, or missed the point. In fact, anyone can do MITM (ssl 
bump) for https running through its system.
It is only question of making it undetected and then you have a choice 
described in the quote above.


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

Re: http subversion URLs should be discontinued in favor of https URLs

[Eugene Grosbein]

11.12.2017 3:52, Franco Fichtner wrote:

>> On 10. Dec 2017, at 9:45 PM, Eugene Grosbein  wrote:
>>
>> 11.12.2017 3:37, Yuri wrote:
>>
>>> On 12/10/17 11:37, Eugene Grosbein wrote:
 Hmm, you should not pass your traffic through the network operated
 by lots of malicious operators in first place. No matter encrypted or not.
 There are plenty of alternative ways.
>>>
>>>
>>> Modern encryption protocols allow you to send traffic over insecure 
>>> networks and still maintain your security and privacy, so why not?
>>
>> No, they don't. You get into MITM and then you have a choice: ignore and run 
>> your connection anyway
>> or have no connectivity at all (using this channel). Both are bad, so don't 
>> use such a channel from the beginning.
> 
> You deconstructed the point you tried to make:
> 
> With HTTP MITM you don't have a choice.  ;)

Whith HTTP going through another route you could have no MITM
because a) MITM is illegal for network provider and/or
b) nobody on this route cares of this HTTP connection (opposed to TOR operator).

Let's get it to real threat model instead of fictional one?

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

Re: http subversion URLs should be discontinued in favor of https URLs

[Yuri]

On 12/10/17 12:45, Eugene Grosbein wrote:

11.12.2017 3:37, Yuri wrote:


On 12/10/17 11:37, Eugene Grosbein wrote:

Hmm, you should not pass your traffic through the network operated
by lots of malicious operators in first place. No matter encrypted or not.
There are plenty of alternative ways.


Modern encryption protocols allow you to send traffic over insecure networks 
and still maintain your security and privacy, so why not?

No, they don't. You get into MITM and then you have a choice: ignore and run 
your connection anyway
or have no connectivity at all (using this channel). Both are bad, so don't use 
such a channel from the beginning.


There's no MITMing with https unless you are a state actor. There are 
very few state actors, they are special case.

Regular hackers can't MITM https, but can MITM http.

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

Re: http subversion URLs should be discontinued in favor of https URLs

[Franco Fichtner]

> On 10. Dec 2017, at 9:45 PM, Eugene Grosbein  wrote:
> 
> 11.12.2017 3:37, Yuri wrote:
> 
>> On 12/10/17 11:37, Eugene Grosbein wrote:
>>> Hmm, you should not pass your traffic through the network operated
>>> by lots of malicious operators in first place. No matter encrypted or not.
>>> There are plenty of alternative ways.
>> 
>> 
>> Modern encryption protocols allow you to send traffic over insecure networks 
>> and still maintain your security and privacy, so why not?
> 
> No, they don't. You get into MITM and then you have a choice: ignore and run 
> your connection anyway
> or have no connectivity at all (using this channel). Both are bad, so don't 
> use such a channel from the beginning.

You deconstructed the point you tried to make:

With HTTP MITM you don't have a choice.  ;)


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

Re: http subversion URLs should be discontinued in favor of https URLs

[Eugene Grosbein]

11.12.2017 3:37, Yuri wrote:

> On 12/10/17 11:37, Eugene Grosbein wrote:
>> Hmm, you should not pass your traffic through the network operated
>> by lots of malicious operators in first place. No matter encrypted or not.
>> There are plenty of alternative ways.
> 
> 
> Modern encryption protocols allow you to send traffic over insecure networks 
> and still maintain your security and privacy, so why not?

No, they don't. You get into MITM and then you have a choice: ignore and run 
your connection anyway
or have no connectivity at all (using this channel). Both are bad, so don't use 
such a channel from the beginning.


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

Re: http subversion URLs should be discontinued in favor of https URLs

[Yuri]

On 12/10/17 11:37, Eugene Grosbein wrote:

Hmm, you should not pass your traffic through the network operated
by lots of malicious operators in first place. No matter encrypted or not.
There are plenty of alternative ways.



Modern encryption protocols allow you to send traffic over insecure 
networks and still maintain your security and privacy, so why not?



Yuri

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

Re: http subversion URLs should be discontinued in favor of https URLs

[Eugene Grosbein]

11.12.2017 2:23, Yuri wrote:

> On 12/10/17 10:15, Igor Mozolevsky wrote:
>> They are not "hypothetical characters," they are invented characters that
>> are used in a threat model. But that's reframing the problem- a
>> hypothetical threat model is very different to a real threat model.
> 
> 
> This is a very real threat model. There are a lot of malicious Tor exit node 
> operators,
> and a lot of FreeBSD users update their system over subversion. The
> only thing that the Tor node operator needs to do is to detect relevant 
> requests and serve malware.

Hmm, you should not pass your traffic through the network operated
by lots of malicious operators in first place. No matter encrypted or not.
There are plenty of alternative ways.

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

Re: http subversion URLs should be discontinued in favor of https URLs

[Poul-Henning Kamp]

In message <898df78d-c0b1-9e9f-0630-2665c3939...@rawbw.com>, Yuri writes:

>3. The user updated the sources through Tor and got hacked.
>
>Where did this user go wrong, or where has he been irresponsible?

He trusted Tor?

In 2006 Steven Murdochs "Hot or Not" work in TCP timers revealed
that a LOT of the Tor network is on a longitude compatible with a
"Bandit of The Beltway" location.

If you still, elleven years later, seriously belive that Tor is
trustworthy, you shouldn't be allowed near any kind of security
decision.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: http subversion URLs should be discontinued in favor of https URLs

[Igor Mozolevsky]

On 10 December 2017 at 19:47, Yuri  wrote:

> On 12/10/17 11:36, Igor Mozolevsky wrote:
>
> If I give my bank card and PIN to someone who I don't trust, I can't
> complain that my bank doesn't take adequate precautions if that person
> drains my bank account! You choose to go down a route that **you** know is
> compromised!
>
>
> 1. The user has set up the subversion source trees based on the *current
> advice* here for anonymous checkout: https://wiki.freebsd.org/
> PortsSubversionPrimer
>
> > % svn co http://svn.freebsd.org/ports/head /usr/ports
>
> 2. The user heard that Tor improves his anonymity, and decided to use it.
>
> 3. The user updated the sources through Tor and got hacked.
>
> Where did this user go wrong, or where has he been irresponsible?
>
>
> The fact that this page https://wiki.freebsd.org/PortsSubversionPrimer still 
> recommends http is appalling!
>
>
The freebsd wiki doesn't recommend Tor, does it?! If the user was so badly
educated about Tor, why is it FreeBSD's problem, honestly? What you're
saying is no different, than "Alice" doesn't want to download FreeBSD
herself, so she asks "Eve" to get her a CD with the source code.
Unbeknownst to Alice, Eve replaces a bunch of files on the CD and present
the CD to Alice as a bona fide copy. The problem in the chain is Eve (or
Tor, in your case) not where Eve got the CD from!

This discussion is turning circular and, quite frankly, ridiculous!

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

Re: http subversion URLs should be discontinued in favor of https URLs

[Igor Mozolevsky]

On 10 December 2017 at 19:42, John-Mark Gurney  wrote:

> Igor Mozolevsky wrote this message on Sun, Dec 10, 2017 at 19:17 +:






> No, I'm saying it's not a realistic threat model! If the threat is the
> > integrity of the source code in transit, then it'd be way cheaper and way
> > more reasonable to implement a Merkle Tree-like verification with each
> > revision.
>
> Then you should be fine w/ http for banking sites, since it's not realistic
> that your ISP will MITM your connection to steal money from you, right?
> I don't know of a single instance of an ISP MITM'ing banking transactions
> to steal money.




Entirely different threat model that has nothing to do with MITM but a lot
to do with bank-website mimicry! If I connect to MoneyBags, Inc, I want to
be sure that everything I send is received at MoneyBags, Inc, and not
someone pretending to be MoneyBags, Inc. If I connect to svn.example.com,
all I care about is that the Merkle Tree holds, not whether svn.example.com
or svn.middleman.example.com provided it.


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

Re: http subversion URLs should be discontinued in favor of https URLs

[Yuri]

On 12/10/17 11:36, Igor Mozolevsky wrote:

If I give my bank card and PIN to someone who I don't trust, I can't
complain that my bank doesn't take adequate precautions if that person
drains my bank account! You choose to go down a route that*you*  know is
compromised!



1. The user has set up the subversion source trees based on the *current 
advice* here for anonymous checkout: 
https://wiki.freebsd.org/PortsSubversionPrimer



% svn co http://svn.freebsd.org/ports/head /usr/ports


2. The user heard that Tor improves his anonymity, and decided to use it.

3. The user updated the sources through Tor and got hacked.

Where did this user go wrong, or where has he been irresponsible?


The fact that this page https://wiki.freebsd.org/PortsSubversionPrimer still 
recommends http is appalling!


Yuri

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

Re: http subversion URLs should be discontinued in favor of https URLs

[John-Mark Gurney]

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, John-Mark Gurney  wrote:
> > >
> > > 
> > >
> > > > The discussion has been for svn updates over http, not for
> > freebsd-update
> > > > updates which are independantly signed and verified..  There is
> > currently
> > > > no signatures provided via SVN to validate any source received via
> > http.
> > >
> > > There has been no instance of in-transit compromise reported since SVN
> > was
> > > introduced.
> >
> > So, you require an exploit in the wild before you'll patch?
> 
> No, I'm saying it's not a realistic threat model! If the threat is the
> integrity of the source code in transit, then it'd be way cheaper and way
> more reasonable to implement a Merkle Tree-like verification with each
> revision.

Then you should be fine w/ http for banking sites, since it's not realistic
that your ISP will MITM your connection to steal money from you, right?
I don't know of a single instance of an ISP MITM'ing banking transactions
to steal money.

-- 
  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
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: http subversion URLs should be discontinued in favor of https URLs

[Igor Mozolevsky]

On 10 December 2017 at 19:31, Yuri  wrote:

> On 12/10/17 11:24, Igor Mozolevsky wrote:
>
> It seems the problem is **not** FreeBSD but Tor in your case!
>
>
> This is the problem of the weakest link in the system which is FreeBSD.
>

If I give my bank card and PIN to someone who I don't trust, I can't
complain that my bank doesn't take adequate precautions if that person
drains my bank account! You choose to go down a route that *you* know is
compromised!


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

Re: http subversion URLs should be discontinued in favor of https URLs

[Yuri]

On 12/10/17 11:24, Igor Mozolevsky wrote:

It seems the problem is*not*  FreeBSD but Tor in your case!



This is the problem of the weakest link in the system which is FreeBSD.


Yuri

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

Re: http subversion URLs should be discontinued in favor of https URLs

[Igor Mozolevsky]

On 10 December 2017 at 19:23, Yuri  wrote:

> On 12/10/17 10:15, Igor Mozolevsky wrote:
>
>> They are not "hypothetical characters," they are invented characters that
>> are used in a threat model. But that's reframing the problem- a
>> hypothetical threat model is very different to a real threat model.
>>
>
>
> This is a very real threat model. There are a lot of malicious Tor exit
> node operators, and a lot of FreeBSD users update their system over
> subversion. The only thing that the Tor node operator needs to do is to
> detect relevant requests and serve malware.
>
> How is this not real?



It seems the problem is *not* FreeBSD but Tor in your case!


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

Re: http subversion URLs should be discontinued in favor of https URLs

[Yuri]

On 12/10/17 10:15, Igor Mozolevsky wrote:

They are not "hypothetical characters," they are invented characters that
are used in a threat model. But that's reframing the problem- a
hypothetical threat model is very different to a real threat model.



This is a very real threat model. There are a lot of malicious Tor exit 
node operators, and a lot of FreeBSD users update their system over 
subversion. The only thing that the Tor node operator needs to do is to 
detect relevant requests and serve malware.


How is this not real?


Yuri

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

Re: http subversion URLs should be discontinued in favor of https URLs

[Igor Mozolevsky]

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, John-Mark Gurney  wrote:
> >
> > 
> >
> > > The discussion has been for svn updates over http, not for
> freebsd-update
> > > updates which are independantly signed and verified..  There is
> currently
> > > no signatures provided via SVN to validate any source received via
> http.
> >
> > There has been no instance of in-transit compromise reported since SVN
> was
> > introduced.
>
> So, you require an exploit in the wild before you'll patch?



No, I'm saying it's not a realistic threat model! If the threat is the
integrity of the source code in transit, then it'd be way cheaper and way
more reasonable to implement a Merkle Tree-like verification with each
revision.


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

Re: http subversion URLs should be discontinued in favor of https URLs

[Igor Mozolevsky]

On 10 December 2017 at 18:01, Yuri  wrote:

> On 12/10/17 09:51, Igor Mozolevsky wrote:
>
>> Hypothetical MITM-bogeyman and "suits not knowing that I use FreeBSD"
>> doesn't make SVN over HTTP insecure.
>>
>
>
> Read here about Alice and Bob: https://en.wikipedia.org/wiki/Alice_and_Bob
>
> Hypothetical characters are commonplace in security discussions.



They are not "hypothetical characters," they are invented characters that
are used in a threat model. But that's reframing the problem- a
hypothetical threat model is very different to a real threat model.


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

Re: http subversion URLs should be discontinued in favor of https URLs

[Yuri]

On 12/10/17 09:51, Igor Mozolevsky wrote:

Hypothetical MITM-bogeyman and "suits not knowing that I use FreeBSD"
doesn't make SVN over HTTP insecure.



Read here about Alice and Bob: https://en.wikipedia.org/wiki/Alice_and_Bob

Hypothetical characters are commonplace in security discussions.


Yuri


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

Re: http subversion URLs should be discontinued in favor of https URLs

[Igor Mozolevsky]

On 10 December 2017 at 17:46, Yuri  wrote:

> On 12/10/17 09:39, Igor Mozolevsky wrote:
>
> There has been no instance of in-transit compromise reported since SVN was
> introduced.
>
> Even when the back-end was compromised, there was not detectable compromise
> of the codebase [1]. So even if the codebase was compromised, unless 
> people**really knew** what they were doing, HTTPS would seed a false sense of
> security.
>
>
> This is another incarnation of the bogus argument: https also has some
> vulnerabilities, so let's just stay with a completely insecure http until
> some ideal solution will be found in the future.
>

Hypothetical MITM-bogeyman and "suits not knowing that I use FreeBSD"
doesn't make SVN over HTTP insecure.


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

Re: http subversion URLs should be discontinued in favor of https URLs

[Poul-Henning Kamp]

In message <20171210174117.gg5...@funkthat.com>, John-Mark Gurney writes:

>> Comcast modifying traffic is a political problem.
>
>Please come the the US and solve this problem for us, since you appare
>to think that it's easy for people like me to solve.

I didn't use the word "easy".

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: http subversion URLs should be discontinued in favor of https URLs

[Igor Mozolevsky]

On 10 December 2017 at 17:41, John-Mark Gurney  wrote:

> Poul-Henning Kamp wrote this message on Sun, Dec 10, 2017 at 17:36 +:





> > >So you're fine w/ all the Comcast users having to switch ISPs?  Because
> > >Comcast modifies traffic.  So you're now saying that if you use FreeBSD
> > >you can't use Comcast as your ISP?
> >
> > Comcast modifying traffic is a political problem.
>
> Please come the the US and solve this problem for us, since you appare
> to think that it's easy for people like me to solve.



Has there been a verifiable instance of Comcast modifying SVN traffic over
HTTP, or do they *merely* use DPI to inject ads into HTML files?


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

Re: http subversion URLs should be discontinued in favor of https URLs

[Yuri]

On 12/10/17 09:39, Igor Mozolevsky wrote:

There has been no instance of in-transit compromise reported since SVN was
introduced.

Even when the back-end was compromised, there was not detectable compromise
of the codebase [1]. So even if the codebase was compromised, unless people
*really knew*  what they were doing, HTTPS would seed a false sense of
security.



This is another incarnation of the bogus argument: https also has some 
vulnerabilities, so let's just stay with a completely insecure http 
until some ideal solution will be found in the future.



Yuri

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

Re: http subversion URLs should be discontinued in favor of https URLs

[Yuri]

On 12/10/17 09:39, Igor Mozolevsky wrote:

There has been no instance of in-transit compromise reported since SVN was
introduced.

Even when the back-end was compromised, there was not detectable compromise
of the codebase [1]. So even if the codebase was compromised, unless people
*really knew*  what they were doing, HTTPS would seed a false sense of
security.



This is another incarnation of the bogus argument: https also has some 
vulnerabilities, so let's just stay with a completely insecure http 
until some ideal solution will be found in the future.



Yuri

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

Re: http subversion URLs should be discontinued in favor of https URLs

[John-Mark Gurney]

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 secure (trusted) connection you do it 
> >> yourself.  You go through other nodes (switches and routers of the 
> >
> >So you're fine w/ all the Comcast users having to switch ISPs?  Because
> >Comcast modifies traffic.  So you're now saying that if you use FreeBSD
> >you can't use Comcast as your ISP?
> 
> Comcast modifying traffic is a political problem.

Please come the the US and solve this problem for us, since you appare
to think that it's easy for people like me to solve.

> Encryption does not solve political problems.

Agreed.  But it is the only tool in my toolbox that can solve it today,
instead of some perfect future that will not happen.

-- 
  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
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: http subversion URLs should be discontinued in favor of https URLs

[Igor Mozolevsky]

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 verified..  There is currently
> no signatures provided via SVN to validate any source received via http.
>
>


There has been no instance of in-transit compromise reported since SVN was
introduced.

Even when the back-end was compromised, there was not detectable compromise
of the codebase [1]. So even if the codebase was compromised, unless people
*really knew* what they were doing, HTTPS would seed a false sense of
security.

There is a number of organisation that your computer is told to trust by
default who have the know-how and capability to mount MITM without one even
knowing unless that one were to manually verify CAs used for host certs,
again, HTTPS doesn't buy anything in that regards.


1. https://www.freebsd.org/news/2012-compromise.html


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

Re: http subversion URLs should be discontinued in favor of https URLs

[Poul-Henning Kamp]

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 secure (trusted) connection you do it 
>> yourself.  You go through other nodes (switches and routers of the 
>
>So you're fine w/ all the Comcast users having to switch ISPs?  Because
>Comcast modifies traffic.  So you're now saying that if you use FreeBSD
>you can't use Comcast as your ISP?

Comcast modifying traffic is a political problem.

Encryption does not solve political problems.


-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: http subversion URLs should be discontinued in favor of https URLs

[John-Mark Gurney]

Igor Mozolevsky wrote this message on Wed, Dec 06, 2017 at 15:04 +:
> On 5 December 2017 at 23:18, RW via freebsd-security <
> freebsd-security@freebsd.org> wrote:
> 
> > On Tue, 5 Dec 2017 14:08:49 -0800
> > Gordon Tetlow wrote:
> >
> >
> > > Using this as a reason to not move to HTTPS is a fallacy. We should do
> > > everything we can to help our end-users get FreeBSD in the most secure
> > > way.
> >
> > I think it's more a question of whether all users should be forced onto
> > https even if it might prevent some users from getting security updates.
> 
> If updates are signed, then I don't see what can be gained by using
> relatively expensive HTTPS over HTTP.

The discussion has been for svn updates over http, not for freebsd-update
updates which are independantly signed and 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."
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: http subversion URLs should be discontinued in favor of https URLs

[John-Mark Gurney]

Michelle Sullivan wrote this message on Fri, Dec 08, 2017 at 21:29 +1100:
> Sorry you want to ensure a secure (trusted) connection you do it 
> yourself.  You go through other nodes (switches and routers of the 

So you're fine w/ all the Comcast users having to switch ISPs?  Because
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."
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: http subversion URLs should be discontinued in favor of https URLs

[John-Mark Gurney]

Eugene Grosbein wrote this message on Wed, Dec 06, 2017 at 04:04 +0700:
> 06.12.2017 3:59, Yuri wrote:
> 
> > It's understood that a lot of arguments can be made for and against this,
> > like with any other issue, but security argument should outweigh most or 
> > all other arguments.
> 
> It is illusion that https is more secure than unencrypted http in a sense of 
> MITM
> just because of encryption, it is not.

Correct, because https doesn't just bring encryption, it also bring
authentication..  https is more secure because of authentication, not
because of encryption...

There are many encryption only protocols that are broken because there
is no authentication provided, allowing MITM..  Which is why self
signed certs that are not pinned are also bad...

IMO, the fact that we are even having this discussion to allow our users
to be MITM like Comcast loves to do[1], is rediculous...  If FreeBSD
wants to be viewed as a secure OS, we need to go https (or other tech),
and drop any unauthenticated methods of distribution of content...

We don't allow freebsd-updates to be distributed w/o being authenticated,
why are we allowing 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

-- 
  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
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: http subversion URLs should be discontinued in favor of https URLs

[Poul-Henning Kamp]

In message <20171208142616.u56ntsf4zx5ns2ey@mutt-hbsd>, Shawn Webb writes:

>It really is a sad state that governments feel they must subvert
>secure communications channels used by citizens. I agree with you
>there.

And it really is a sad state when rabid IT-liberalists don't see
any problem with females who dare to speak out against sexual abuse
being threathened via Tor, teenage girls, whos only crime is looking
good, being sent dick-picks by shitbags and organized crime being
above the law.

>What if FreeBSD generated its own CA for use with critical
>infrastructure, like the svn repo. The trusted CA certificate would be
>distributed via multiple means: in the src tree and on the website.
>It would get installed on user's systems.

*Then* I could see a point in using HTTPS, because then you would
have the FreeBSD Project telling you that you got to the right place
rather than Taiwanese or Turkish government telling you that you
got to what they think is the right place.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: http subversion URLs should be discontinued in favor of https URLs

[Igor Mozolevsky]

On 8 December 2017 at 14:26, Shawn Webb  wrote:




Please note that this is likely to be my only contribution to this
> thread.
>
> What if FreeBSD generated its own CA for use with critical
> infrastructure, like the svn repo.




Nobody has yet offered a concrete threat model that requires such elaborate
investment. So far as I can tell, the only two things people have mentioned
are:

- abstract MITN-bogeyman; or
- not wanting "the suits" learning one is using FreeBSD...


To me, both of the above sound more unjustifiably paranoid than reasonable,
yet the people advocating the above want not only an investment in
elaborate infrastructure, but also waste computer cycles for crypto and
network traffic for re-transmission of static data that is fully capable of
getting cached thereby reducing network/server load at the source. Both
Microsoft (unless you're running an MS-syndicated update server) and
virtually every Linux distro require repeated downloads of the *same* data
(due to HTTPS!) if you have more than one install (I am talking not just
running a bunch of boxes but virtualised machines that people need to
repeatedly create/destroy for whatever reason); that is a sheer insanity
from the NetOps perspective!

The "how do we know security updates are legitimate if they come down a
mere HTTP" is answered by signing the updates themselves, rendering the S
in the HTTPS redundant.


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

Re: http subversion URLs should be discontinued in favor of https URLs

[Shawn Webb]

On Fri, Dec 08, 2017 at 02:07:13PM +, Poul-Henning Kamp wrote:
> 
> In message <2a8d9a0a-7a64-2dde-4e53-77ee52632...@tjvarghese.com>, TJ Varghese 
> w
> rites:
> 
> >I'm curious as to your take on electronic banking.
> 
> Good security is not "all or nothing", it is a carefully calibrated
> application of security measures to the problem at hand.
> 
> By forcing all web-traffic onto HTTPS, the rabid IT-liberalist has
> put governments in a position where they either have to break HTTPS
> traffic open or give up on having a working criminal justice system.
> 
> Anybody with a daughter knows what that dice will roll.
> 
> If you've ever read Clausewitz, you will recognize this strategy
> as really stupid:  *Never* put your enemy in a position where their
> only option is to defeat you.
> 
> Various governments are going about this in different ways, some
> force a trojan root-cert on all their citzens, others pass law
> where you can be jailed indefinitely until you hand over your
> passwords, others again try force the IT-industry to "ensure
> legal access".
> 
> Unfortunately this happens with little or no intelligent and
> cooperative input from the IT-community, who seem hell-bent
> on their "all or nothing" strategy.
> 
> I personally preferred it back when HTTPS was tolerated by governments,
> because everybody could see that banking and e-commerce needed it,
> over the situation now, where HTTPS is so trojaned, that my webbank
> is no longer trustworthy via HTTPS.

It really is a sad state that governments feel they must subvert
secure communications channels used by citizens. I agree with you
there.

Please note that this is likely to be my only contribution to this
thread.

What if FreeBSD generated its own CA for use with critical
infrastructure, like the svn repo. The trusted CA certificate would be
distributed via multiple means: in the src tree and on the website.
It would get installed on user's systems.

The CA cert could have a long lifetime, say twenty years. FreeBSD
would use key material generated by its CA to secure the comms channel
for the critical infrastructure. This key material would have a
significantly shorter lifetime, perhaps six months or one year. Thus,
the private key material for the CA only needs to come out of cold
storage to generate new key material only periodically (hence why the
CA cert can have a long lifetime).

This would accompish multiple goals:

1. It would secure the comms channels for critical infrastructure.
2. It would prevent FreeBSD from being tied to existing CAs, which
   could be compromised or coerced into misbehaving.
3. It keeps FreeBSD in full control of their infrastructure.

FreeBSD already distributes key material for use with pkg (and perhaps
freebsd-update and portsnap (I don't know how those two work
under-the-hood with regards to dsigs)). Distributing one more piece of
key material isn't going to create much overhead.

We at HardenedBSD use a similar method as proposed above for our
binary updates. We use X.509 certificates to create a chain of trust
for our binary updates for base. We maintain our own CA, with the CA
cert having a lifetime of twenty years. The key material used to sign
the update gets regenerated every year on January 1st, but has a
thirteen-month lifespan. The CA key material resides on an encrypted
flash drive, stored in a place that requires two signatures from two
parties and two physical keys, only one of which I hold.

Thanks,

-- 
Shawn Webb
Cofounder and Security Engineer
HardenedBSD

GPG Key ID:  0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE


signature.asc
Description: PGP signature

Re: http subversion URLs should be discontinued in favor of https URLs

[Poul-Henning Kamp]

In message <2a8d9a0a-7a64-2dde-4e53-77ee52632...@tjvarghese.com>, TJ Varghese w
rites:

>I'm curious as to your take on electronic banking.

Good security is not "all or nothing", it is a carefully calibrated
application of security measures to the problem at hand.

By forcing all web-traffic onto HTTPS, the rabid IT-liberalist has
put governments in a position where they either have to break HTTPS
traffic open or give up on having a working criminal justice system.

Anybody with a daughter knows what that dice will roll.

If you've ever read Clausewitz, you will recognize this strategy
as really stupid:  *Never* put your enemy in a position where their
only option is to defeat you.

Various governments are going about this in different ways, some
force a trojan root-cert on all their citzens, others pass law
where you can be jailed indefinitely until you hand over your
passwords, others again try force the IT-industry to "ensure
legal access".

Unfortunately this happens with little or no intelligent and
cooperative input from the IT-community, who seem hell-bent
on their "all or nothing" strategy.

I personally preferred it back when HTTPS was tolerated by governments,
because everybody could see that banking and e-commerce needed it,
over the situation now, where HTTPS is so trojaned, that my webbank
is no longer trustworthy via HTTPS.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: http subversion URLs should be discontinued in favor of https URLs

[Luke Crooks]

The pull request was rejected for a valid reason, offering http allows
users with limited network access chance to clone or download freebsd where
https is not possible. We all have differences of option on the matter and
having a flame war on a mailing list just gives the project a bad
reputation.


Regards,
--
Luke Crooks
Solent Wholesale Carpets
www.solentwholesale.com

On Fri, Dec 8, 2017 at 8:25 AM, TJ Varghese  wrote:

> On 12/07/2017 10:50 PM, Poul-Henning Kamp wrote:
>
>>
>> You can't have the latter without the former.  Assertion of identity is
>>> the only protection against MITM eavesdropping or tampering.
>>>
>> Or more generally:
>>
>> If you dont/cant trust the other end, why would you trust them to
>> keep the communication secret ?
>>
>>
> I'm curious as to your take on electronic banking. Should they all merely
> use HTTP since HTTPS is hopelessly compromised by design? If your objection
> is that HTTPS bring nothing to the security table, then it really doesn't
> make a difference where it's used and we should all just stop using it, no?
>
>
>
>
> ___
> freebsd-security@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org
> "
>
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: http subversion URLs should be discontinued in favor of https URLs

[Michelle Sullivan]

Yuri wrote:

On 12/07/17 15:16, Jason Hellenthal wrote:
The truly paranoid types that don’t want anyone to know they are 
using FreeBSD apparently.


Honestly if they are that worried about http then get a private vpn 
tunnel and run through that instead !



Some people aren't aware that they use http, and enable Tor because 
they think that it improves privacy. It's very easy to use such setup 
inadvertently.



Ding! Ding! Ding! we have a winner!

This is about privacy and anonymity rather than security then...

Sorry you want to ensure a secure (trusted) connection you do it 
yourself.  You go through other nodes (switches and routers of the 
normal internet) you make a choice... do I trust them to deliver my 
packets untampered with or not?  I know there are nodes out there that 
are doing monitoring and filtering and even returning bad data 
(accessing a certain 58 servers/IPs in Australia will have all HTTP 
spoofed to return a static message that has nothing to do with those 58 
servers... I now run a proxy on a network I trust and a VPN to that 
network (all of which are in Australia) and don't have my packets 
intercepted.)


If you're running your connection over Tor, you're running over a second 
layer with people out there that are not even necessarily trustworthy, 
many are people that they themselves use Tor for legally questionable 
actions, many for perfectly valid (though legally questionable) 
reasons.. (think: penetration testers - even commissioned ones).. but by 
using Tor you are accepting the risks in the knowledge that your data is 
traversing a network where people with questionable legal 
motives/positions...


So basically you want everyone to double their resources so that you can 
risk using an inherently untrustable network in the name of privacy... 
which in many cases you won't have anyway (because if the person doesn't 
know they are using http, then there is a pretty good chance they 
haven't secured their browser so it's spewing tracking cookies and other 
privacy defeating headers anyhow!)


Enough please!

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

Re: http subversion URLs should be discontinued in favor of https URLs

[TJ Varghese]

On 12/07/2017 10:50 PM, Poul-Henning Kamp wrote:



You can't have the latter without the former.  Assertion of identity is
the only protection against MITM eavesdropping or tampering.

Or more generally:

If you dont/cant trust the other end, why would you trust them to
keep the communication secret ?



I'm curious as to your take on electronic banking. Should they all 
merely use HTTP since HTTPS is hopelessly compromised by design? If your 
objection is that HTTPS bring nothing to the security table, then it 
really doesn't make a difference where it's used and we should all just 
stop using it, no?




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

Re: http subversion URLs should be discontinued in favor of https URLs

[Matthew Finkel]

On Thu, Dec 07, 2017 at 10:26:06PM +, Poul-Henning Kamp wrote:
> 
> In message <2a6d123c-8ee5-8e1e-d99b-4bce02345...@rawbw.com>, Yuri writes:
> 
> >The unfortunate FreeBSD user who updated his source tree through 
> >Tor [...]
> 
> Why would anybody do that in the first place ?

Why doesn't everyone have that option? Why is broadcasting a users information
across the internet forced upon them? Shouldn't they have a choice?

I don't disagree the CA mafia model is a broken mess, but there is some work
being done for this - so maybe the situation will be better in 5-10 years. But
even with those improvements, I'd rather have updates served over a
self-authenticating onion service than over a direct http connection. I see
five options: direct-http-connection, direct-https-connection, http-over-tor,
https-over-tor, and http-over-onion. There is only one of these that does not
require trusting the intermediate hops of the connection (or external third
parties) and it guarantees the bits that went in at one end of the connection
are the bits that come out the other end while not leaking sensitive
information (metadata) along the path.

As a concrete example, I encourage everyone read why Debian chose exactly this
solution[0][1].

It would be nice if all updates are available over onion, not only subversion,
but subversion is a good starting point. Onion services accomplish the same
basic goal as TLS (authentication, integrity, confidentiality) and they protect
against targetting and profiling users. As a user, I care about all these
problems.

Also, to Yuri's original point, you can ship a self-signed FreeBSD CA cert.
Subversion supports using it, so beside getting the private keys on the
mirrors there is little against doing it[2].

[0] https://blog.torproject.org/tor-heart-apt-transport-tor-and-debian-onions
[1] 
https://bits.debian.org/2016/08/debian-and-tor-services-available-as-onion-services.html
[2] http://svnbook.red-bean.com/en/1.7/svn-book.html#svn.serverconfig.httpd.ssl
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: http subversion URLs should be discontinued in favor of https URLs

[Poul-Henning Kamp]

In message <83e44188-6e0d-13cc-4b80-d191ac010...@rawbw.com>, Yuri writes:
>On 12/07/17 15:16, Jason Hellenthal wrote:
>> The truly paranoid types that don’t want anyone to know they are using 
>> FreeBSD apparently.
>>
>> Honestly if they are that worried about http then get a private vpn tunnel 
>> and run through that instead !
>
>
>Some people aren't aware that they use http, and enable Tor because they 
>think that it improves privacy. It's very easy to use such setup 
>inadvertently.

And for this reason you want the FreeBSD project to take a politically
stupid position in the war between IT-liberalists and all the worlds
governments ?

No thanks.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: http subversion URLs should be discontinued in favor of https URLs

[Yuri]

On 12/07/17 15:16, Jason Hellenthal wrote:

The truly paranoid types that don’t want anyone to know they are using FreeBSD 
apparently.

Honestly if they are that worried about http then get a private vpn tunnel and 
run through that instead !



Some people aren't aware that they use http, and enable Tor because they 
think that it improves privacy. It's very easy to use such setup 
inadvertently.



Yuri

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

Re: http subversion URLs should be discontinued in favor of https URLs

[Jason Hellenthal]

The truly paranoid types that don’t want anyone to know they are using FreeBSD 
apparently.

Honestly if they are that worried about http then get a private vpn tunnel and 
run through that instead !

> On Dec 7, 2017, at 16:27, Poul-Henning Kamp  wrote:
> 
> 
> In message <2a6d123c-8ee5-8e1e-d99b-4bce02345...@rawbw.com>, Yuri writes:
> 
>> The unfortunate FreeBSD user who updated his source tree through 
>> Tor [...]
> 
> Why would anybody do that in the first place ?
> 
> -- 
> Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
> p...@freebsd.org | TCP/IP since RFC 956
> FreeBSD committer   | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
> ___
> freebsd-security@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
> 
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: http subversion URLs should be discontinued in favor of https URLs

[Poul-Henning Kamp]

In message <2a6d123c-8ee5-8e1e-d99b-4bce02345...@rawbw.com>, Yuri writes:

>The unfortunate FreeBSD user who updated his source tree through 
>Tor [...]

Why would anybody do that in the first place ?

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: http subversion URLs should be discontinued in favor of https URLs

[Yuri]

On 12/05/17 12:59, Yuri wrote:
I suggested this PR, but it got rejected: 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224097



http is insecure in its nature, and is an easy target for MITM. This 
is why https should be preferred. http needs to be discontinued and 
shut down because as long as it exists somebody will keep using it and 
will be in danger.



Few years ago Wikimedia Foundation switched to https and discontinued 
http entirely: 
https://blog.wikimedia.org/2015/06/12/securing-wikimedia-sites-with-https 
I think this makes a lot of sense, and FreeBSD should do the same.



It's understood that a lot of arguments can be made for and against 
this, like with any other issue, but security argument should outweigh 
most or all other arguments.




Let's forget about all the abstract arguments and considerations, and 
consider this concrete scenario:


Let's assume there is the malicious hacker who runs the malicious Tor 
exit node. In his attempt to spread malware, he watches all outbound 
http traffic for subversion requests to the domain FreeBSD.org. Once he 
detects such request, he serves the maliciously patched versions of 
popular ports and kernel in a hope that they will be rebuilt locally and 
run. The unfortunate FreeBSD user who updated his source tree through 
Tor got infected. This can't possibly happen if https protocol was in 
use, because the hacker is just a private person and doesn't have access 
to any CA authorities, and doesn't impersonate anybody.


Please justify the use of the http protocol in the face of this scenario.


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

Re: http subversion URLs should be discontinued in favor of https URLs

[Poul-Henning Kamp]

In message <867etyzlad@desk.des.no>, =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= w
rites:
>Gordon Tetlow  writes:
>> Assertion of identity and encryption in transit are separate issues. [...]
>
>You can't have the latter without the former.  Assertion of identity is
>the only protection against MITM eavesdropping or tampering.

Or more generally:

If you dont/cant trust the other end, why would you trust them to
keep the communication secret ?

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: http subversion URLs should be discontinued in favor of https URLs

[Dag-Erling Smørgrav]

Gordon Tetlow  writes:
> Assertion of identity and encryption in transit are separate issues. I
> do agree that identity is fundamentally broken with the existing CA
> system. I’m more interested in preventing tampering of data in
> transit. HTTPS is an easy way to do that.

You can't have the latter without the former.  Assertion of identity is
the only protection against MITM eavesdropping or tampering.

DES
-- 
Dag-Erling Smørgrav - d...@des.no
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: http subversion URLs should be discontinued in favor of https URLs

[Igor Mozolevsky]

On 5 December 2017 at 23:18, RW via freebsd-security <
freebsd-security@freebsd.org> wrote:

> On Tue, 5 Dec 2017 14:08:49 -0800
> Gordon Tetlow wrote:
>
>
> > Using this as a reason to not move to HTTPS is a fallacy. We should do
> > everything we can to help our end-users get FreeBSD in the most secure
> > way.
>
> I think it's more a question of whether all users should be forced onto
> https even if it might prevent some users from getting security updates.



If updates are signed, then I don't see what can be gained by using
relatively expensive HTTPS over HTTP.

People screaming for HTTPS without justifying a specific threat model (cf.
a generic "MITM"-bogeyman), don't understand HTTPS nor general security (to
paraphrase the famous phrase).

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

Re: http subversion URLs should be discontinued in favor of https URLs

[Karl Denninger]

On 12/6/2017 08:17, Cy Schubert wrote:
>
>> It can be illusory.   My last job was as Sec Mgr for a large bank.  They
>> disabled cert checking on client devices, placed a wildcard cert at the
>> internet boundary and captured all https unencrypted.  An alternative
>> approach to advocate is dnssec.  :)
> And you just let this happen under your watch?

The reason such is done is that the IT people /have /thought about it
and determined that being able to /scan and archive /all traffic going
in and out is worth more than the "security" afforded by allowing HTTPS
originated beyond their border in.  Oh by the way in some lines of
business said ability to scan and archive is a matter//of regulatory
compliance...

I'm not, by the way, opining on whether this is a correct analysis or
not. But I will note for the record that Avast's anti-virus products
will, by default, do exactly this sort of intentional interception on
IMAP server traffic aimed at port 993 in an attempt to detect trojans
and viruses that are attached to email messages.

-- 
Karl Denninger
k...@denninger.net 
/The Market Ticker/
/[S/MIME encrypted email preferred]/


smime.p7s
Description: S/MIME Cryptographic Signature

RE: http subversion URLs should be discontinued in favor of https URLs

[Cy Schubert]

No worries, telnet and ftp are in my sights.

---
Sent using a tiny phone keyboard.
Apologies for any typos and autocorrect.
This old phone only supports top post. Apologies.

Cy Schubert
<cy.schub...@cschubert.com> or <c...@freebsd.org>
The need of the many outweighs the greed of the few.
---

-Original Message-
From: Steve Clement
Sent: 06/12/2017 03:29
To: Dewayne Geraghty
Cc: freebsd-security@freebsd.org
Subject: Re: http subversion URLs should be discontinued in favor of https URLs

* On Wed, Dec 06, 2017 at 08:55:00AM +1100, Dewayne Geraghty 
<dewayne.gerag...@heuristicsystems.com.au> wrote:
> On 6/12/2017 8:13 AM, Yuri wrote:
> > On 12/05/17 13:04, Eugene Grosbein wrote:
> >> It is illusion that https is more secure than unencrypted http in a
> >> sense of MITM
> >> just because of encryption, it is not.
> >
> >

Dear all,

Is it really wise suggesting that http is not that bad?

While you are at it, perhaps reviving telnet is a good idea. (Yes it is a
bad comparison)

If your answer is to just not use it, good luck for the past.

> It can be illusory.   My last job was as Sec Mgr for a large bank.  They
> disabled cert checking on client devices, placed a wildcard cert at the
> internet boundary and captured all https unencrypted.  An alternative
> approach to advocate is dnssec.  :)

And you just let this happen under your watch?

> You also need to ensure integrity, to ensure that the numbers are
> flipped in transit...  ;)

As a security person you do have responsibilities. Of course if you (as a
security person) gave up on all that, you might as well go to the beach and
use your CB to talk to your Dr.

I cannot believe these attitudes, can perhaps other people weigh-in,
especially to the issue at hand?

Looking forward to the first person brining up performance issues, in
end-of-2017…

Sincerely yours,

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

Re: http subversion URLs should be discontinued in favor of https URLs

[Eugene Grosbein]

On 06.12.2017 05:08, Gordon Tetlow wrote:

> Using this as a reason to not move to HTTPS is a fallacy. We should do
> everything we can to help our end-users get FreeBSD in the most secure
> way.

Please do not mix opportunity with enforcement.


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

Re: http subversion URLs should be discontinued in favor of https URLs

[Slawa Olhovchenkov]

On Tue, Dec 05, 2017 at 01:13:25PM -0800, Yuri wrote:

> On 12/05/17 13:04, Eugene Grosbein wrote:
> > It is illusion that https is more secure than unencrypted http in a sense 
> > of MITM
> > just because of encryption, it is not.
> 
> 
> It *is* more secure.

https don't work frequent than http and this is not secure.
___
freebsd-security@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"

Re: http subversion URLs should be discontinued in favor of https URLs

[Dan Lukes]

It is illusion

As a security person you do have responsibilities


Lets calm down, guys. Anyone can claim "I'm skilled security officer".

But true professional will define the risk to mitigate *first*.
We can discuss possible solutions *then*.

Flamewars "https will save our souls" v.s. "https is illusion of 
security" with fuzzy goal helps to no one.


Just my $0.02

Dan

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

Re: http subversion URLs should be discontinued in favor of https URLs

[Steve Clement]

* On Wed, Dec 06, 2017 at 08:55:00AM +1100, Dewayne Geraghty 
 wrote:
> On 6/12/2017 8:13 AM, Yuri wrote:
> > On 12/05/17 13:04, Eugene Grosbein wrote:
> >> It is illusion that https is more secure than unencrypted http in a
> >> sense of MITM
> >> just because of encryption, it is not.
> >
> >

Dear all,

Is it really wise suggesting that http is not that bad?

While you are at it, perhaps reviving telnet is a good idea. (Yes it is a
bad comparison)

If your answer is to just not use it, good luck for the past.

> It can be illusory.   My last job was as Sec Mgr for a large bank.  They
> disabled cert checking on client devices, placed a wildcard cert at the
> internet boundary and captured all https unencrypted.  An alternative
> approach to advocate is dnssec.  :)

And you just let this happen under your watch?

> You also need to ensure integrity, to ensure that the numbers are
> flipped in transit...  ;)

As a security person you do have responsibilities. Of course if you (as a
security person) gave up on all that, you might as well go to the beach and
use your CB to talk to your Dr.

I cannot believe these attitudes, can perhaps other people weigh-in,
especially to the issue at hand?

Looking forward to the first person brining up performance issues, in
end-of-2017…

Sincerely yours,

Steve


signature.asc
Description: PGP signature

Re: http subversion URLs should be discontinued in favor of https URLs

[Michelle Sullivan]

Yonas Yanfa wrote:


I wholeheartedly agree with Gordon. Let's do more, not less.

I believe it was fallacies like this that mislead many websites, 
including freebsd.org, to remain in HTTP for far too long.


Oh good God! What is 'in the name of security' is this crusade making 
all - plain text, publicly accessible, static content sites 'HTTPS' 
instead of 'HTTP' ?  Bearing in mind its trivial to block anyhow, 
using a modern up to date browser if I block (send back resets - ie 
"connection refused") a connection to a client making a secure request 
to the web and the user has not explicitly set https:// as the start of 
the URL it (the browser) will automatically try port 80 (http) for the 
connection, I am now quite easily able to MITM attack the user by 
proxying (and re-writing) the http:// requests into https:// requests to 
the real webserver which might have disabled http:// connections "in the 
name of security" ...


Now not saying that this is an issue on subversion requests as usually 
they are specific in their requests to use a secure layer or not but 
lets get real here, the protocol allows secure and insecure, you should 
use the secure by default.  You should not automatically not use any 
insecure, or worse restrict access to secure only in the name of 
progress because those sites secured with their own project certificates 
(self-signed) will see people just turning off checking of the signers, 
and therefore will turn off checking of CRLs and you will lower overall 
security Its like making passwords change every week and have to be 
>20 characters with upper lower and special... result is security is 
lowered because people write them down.


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