https

[Josh B.]

All Racket domains should be available via https, and should redirect from http to https. SSL certificates can now be obtained for free thanks to LetsEncrypt. And since CloudFlare announced Universal SSL over a year ago, it has been possible—for free—to encrypt the connection between the visitor's browser and the CloudFlare reverse proxy, even if the connection between the CloudFlare proxy and the origin server is unencrypted, using the Flexible SSL configuration. (Of course end-to-end encryption is better, but in this case some encryption is better than none.)

Are there any plans to do this? I have upgraded several sites to https and if I can help with this effort, please don't hesitate to contact me. I'm based in Providence and know Shriram and Jay from when I was an undergrad in Brown CS.

Josh

[Matthew Flatt]

Yes, definitely. I was looking at CloudFlare as an option just
yesterday, and it would be great to have help on this, so I will be in
touch.

> --
> You received this message because you are subscribed to the Google Groups
> "Racket Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-dev+...@googlegroups.com.
> To post to this group, send email to racke...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-dev/a8b36376-7ae4-4a51-916f-f7bc5dfe97
> 1f%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Neil Van Dyke]

HTTPS should be the default for Racket package directory Web and
webservice requests, and for any Racket server stuff that *requires*
privileged access -- just as good practice, on balance.

After that point, however, the recent calls for "HTTPS everywhere" by
well-meaning people (and perhaps a few non-well-meaning people) become
more complicated, with adverse privacy implications that might not be
intuitive at first. (This domain is much more complicated than
thwarting a casual snoop on open WiFi, or thinking that server operators
would actually be permitted to thwart the enn-ess-ay. And I see at
least three big privacy downsides to "HTTPS everywhere" that can further
the goals of the big commercial privacy adversaries, as well as those of
state actors. I'm not including better-known flaws of the current HTTPS
SSL trusted certs approach in the three downsides.)

These assertions of downsides are a good puzzle for students to
solve... Two of the downsides will become obvious once you understand
the ways contemporary commercial snooping happens -- which understanding
includes examining what you can of the real-world practice yourself,
since little is written about it, and also disregarding most privacy
activists. The third downside might require learning about general
desired capabilities of privacy/security adversaries, and considering
that currently mitigating realities that will come to mind will be
affected by where some of the browser developers are now going with
internal security robustness.

Neil V.

[jabronson]

Some relevant links:

- https://en.wikipedia.org/wiki/XcodeGhost (the "Reflections on Trusting Trust" connection is not lost on me;)

- http://blog.ontoillogical.com/blog/2014/07/28/how-to-take-over-any-java-developer/

- https://developers.google.com/web/fundamentals/security/encrypt-in-transit/why-https?hl=en

I'd be interested to hear more of your thoughts, if you'd like to email me off-list. In the meantime, I'm glad Racket is moving to distributing software securely. Ideally it would also be signed, and checksums would be published too.

[Neil Van Dyke]

jabronson wrote on 12/22/2015 10:26 PM:
> On Sun, Dec 20, 2015 at 1:53 PM, Neil Van Dyke <ne...@neilvandyke.org
> <mailto:ne...@neilvandyke.org>> wrote:
>
> HTTPS should be the default for Racket package directory Web and
> webservice requests, and for any Racket server stuff that
> *requires* privileged access -- just as good practice, on balance.
>

[...]

>
> I'm glad Racket is moving to distributing software securely. Ideally
> it would also be signed, and checksums would be published too.

Simple per-author package signing might be good, though it can be
burdensome when package authors go to the work to use good key
management. (Racket third-party package releases have moved more
towards casual "here's my Git URL; guess I'm done", so we might have to
shake up current expectations of minimal practices for version releases,
before I think we could hope for many authors to keep their keys
passably secure, and also not lose the keys.)

I'm sure signing has been suggested a few times for Racket package
systems, and the first hit I got in Google was actually by me:

"http://lists.racket-lang.org/users/archive/2003-March/002004.html" says:
> [...] Speaking of the author as a semi-trusted authority, there's a
> truly nasty threat in network software distribution systems of
> trojaned code,which we need to acknowledge. The biggest risk may be
> when author A's package is well-established and widely used, so bad
> guy B uploads a trojaned update. Very simple GnuPG signing of
> packages by the authors would be a good way to reduce this threat.
> The CSPAN user update program could automatically verify the
> signature, and the author program could offer to sign the package
> before uploading to CSPAN. There need not even be a centralized key
> ring -- simply knowing that the same key that signed your current
> version signed the new version would make things harder for a badguy.
> Signing doesn't need to be in the first release of CSPAN tools, but I
> think they should be designed to easily accomodate author-signing
> later. (I'm intentionally avoiding the idea of bureaucratic signing
> by separate reviewers, etc.) [...]

(I think "CSPAN" was probably an earlier name of the cleverly-named
"PLaneT", which was the first Racket package system.)

Later, I had some actual research-y ideas about how to increase package
security confidence with PLaneT, but that got interrupted.

(BTW, "Xc*d*Gh*st" was a great "Reflections on Trusting Trust" example,
as you say, and indeed is relevant to distributions of core Racket.
However, assuming that none of the app developers was complicit, HTTPS
of course wouldn't have helped the developers, if the downloadable
software was already compromised on the server. And official checksums
for "mirrored" software copies might not helped in this case, such as
(hypothetically) if one checks against an official checksum that was
conveyed to one -- even via HTTPS from a believed-legitimate authority
-- but one's adversary controls one's Internet pipe and a trusted CA.
And that's before we get to the possibility of developers' machines
being compromised, which isn't so unlikely. It's good to be reminded
that even simple things in security are difficult.)

Neil V.

[jabronson]

On Wed, Dec 23, 2015 at 12:29 AM, Neil Van Dyke <ne...@neilvandyke.org> wrote:

(BTW, "Xc*d*Gh*st" [...] is relevant to distributions of core Racket.  However, [...] HTTPS of course wouldn't have helped the developers, if the downloadable software was already compromised on the server.

(XcodeGhost highlights the importance of code signing or validating the checksum of an insecure download—e.g. one retrieved over http, or from an unofficial mirror—against a securely-retrieved official checksum. If the developers in China had run "codesign -dv" on their download before trusting it, it could have caught this. In general, the more software installation tools and operating systems can automatically enforce protections like these, the better.

- https://wiki.debian.org/SecureApt

- https://en.wikipedia.org/wiki/Gatekeeper_(OS_X)

- https://wiki.mozilla.org/Add-ons/Extension_Signing

- etc.

)

[Neil Van Dyke]

jabronson wrote on 12/23/2015 05:45 PM:
> (XcodeGhost highlights the importance of code signing or validating
> the checksum of an insecure download—e.g. one retrieved over http, or
> from an unofficial mirror

[...]

> - https://wiki.debian.org/SecureApt
> - https://en.wikipedia.org/wiki/Gatekeeper_(OS_X)

> <https://en.wikipedia.org/wiki/Gatekeeper_%28OS_X%29>

> - https://wiki.mozilla.org/Add-ons/Extension_Signing
> - etc.

If you're saying that core Racket should participate in OS/distro
vendor's signing system for the download of core Racket, that sounds OK.

If you're saying that Racket should have a signing system for
third-party packages, I've advocated that myself -- *but* it is
important to have an *appropriate* signing system, not merely *a*
signing system, and this is harder than it seems, especially if starting
with bad-influence role models.

The Debian approach is fine for Debian (it's worked OK for a long time,
and isn't snoopy or too authoritarian, and it pushes Debian's security
weak-links elsewhere), though not a drop-in for third-party Racket
packages. The proposed Mozilla signing system is creepy in context
(especially when you consider what pressures Mozilla is under, and some
of the pressures they seem likely to be under in the future, and
considering their spotty track record), and I'd suspect that the FSF
will have renewed interest in a Firefox fork because of this. Regarding
OS X Gatekeeper, I don't know how Apple is currently using that on OS X,
but students should look at the history of how Apple has used the iOS
App Store approval process and retroactive deletion in an abusive and
anticompetitive way (which has been a big deal, and should be a textbook
case, despite its omission from the Wikipedia page) -- it's arguably
first about strangehold middleman revenue and ongoing competition
elimination, and only second about security/quality/brand control.

One of the reasons I mention this is due to the education-heavy slant of
the Racket community. There is a cliché in IT security (actually
pervading many aspects of IT, but perhaps most painful in security), of
thinking "X will solve this security problem", which might or might not
be true, and then proceeding to do X in a very wrong way. For example,
I think Schneier's introductory crypto book is one that points out,
something like, homebrew applications of crypto seem to inevitably be
incorrect, and I've seen many real-world examples of this. What it
often reduces to is people not understanding the tools they're trying to
work with: like someone being sick, and thinking they need "medicine",
and they know that a particular antibiotic is strong. Or someone
needing to clean the floors, and thinking making a cleaning solution
from bleach and ammonia will work even better. These sound ridiculous,
but so is how IT security is usually implemented. Students should
appreciate this reality, and how it affects the industry examples they
see, and know that they have to work actively to avoid the bad practices
in their own work.

Even Racket is not immune to mistakes of enthusiasm and overconfidence
-- and everyone has made, and will occasionally continue to make,
mistakes of this kind. But security/privacy (and impositions on users
and volunteers) are some of the last places we least want to make big
mistakes. So, when we think "we need X security", I think there's a
burden on us to understand the problem well. And, bad prevailing
practices mean that we might also want to communicate that understanding.

Neil V.