Slashdot Mirror
SourceForge Introduces HTTPS Support For Project Websites (sourceforge.net)
SourceForge announced on Wednesday that it is introducing HTTPS for all project websites on its platform. Once a project has been moved to HTTPS, old domain will automatically redirect to their new counterparts, resulting in no loss of traffic or inconvenience. From a blog post on the site: With a single click, projects can opt-in to switch their web hosting from http://name.sourceforge.net to https://name.sourceforge.io. Project admins can find this option in the Admin page, under "HTTPS", naturally.There's also a guide to assist developers with the transition. SourceForge launched HTTPS support for SourceForge.net back in February, but this rolls out HTTPS support to individual project websites hosted on SourceForge. There's also a Site News section on the website now where you can read about all SourceForge changes and improvements over the past year since SourceForge was acquired by BIZX, such as eliminating the DevShare program and scanning all projects for malware.
Hello symantec (it's the actual owner of SF?)
Nice to see this little change.
Everyone else are on the boat.
Is that still a thing?
I thought sourceforge was one of the bad guys now that they're manipulating projects irrespective of those project maintainers...
Do not look into laser with remaining eye.
".io"? Seriously? So lame.
Is sourceforge even real anymore, or are they just a crapware distribution CDN?
Source forge is incredibly annoying to use, and git/github/bitbucket have all pretty much become the ubiquitous tools for hosting projects on. If I find an OS project on SoureForge, I assume it is long since abandoned.
https://en.wikipedia.org/wiki/... .io is the country code for the British Indian Ocean Territory.
I appreciate the changes SF has made, but in January I moved my web hosting from Sourceforge to my own infrastructure. Now I have HTTPS, can make outbound HTTP calls, have more control over the backend, and the web site is 10x faster. It does not cost much, and with reverse proxies, I was able to weather several huge traffic spikes without a blip.
Now that all active projects are on github . . .
Why does everything need to be encrypted. It's only if you are doing something bad that you need encryption. Everyone should know everybody else's password.
https on "social" sites (non bank/finance/medical...etc ones traditionally needing encryption), mostly benefits the site -- not so much most user. It usually harms users more than not as it prevents content caching and local-filtering. On a https site, I can cache near zero in my squid proxy (used by more than one account & user). That allows much tighter tracking of individuals as they go from site to site.
On news and discussion sites, I can easily get over 25% of the requests satisfied locally -- and housemates notice the difference -- especially on things like heavily thumbnail'd sites like youtube.
Think twice about https everywhere, as it ends up with the standard being that gateway owners (companies or individuals) need to install ways to overcome that.
That harms "sensitive-sites" that really should use https, (finance, medical, etc).
"scanning all projects for malware"
Irony!
https on "social" sites (non bank/finance/medical...etc ones traditionally needing encryption), mostly benefits the site -- not so much most user. It usually harms users more than not as it prevents content caching and local-filtering. On a https site, I can cache near zero in my squid proxy (used by more than one account & user). That allows much tighter tracking of individuals as they go from site to site.
On news and discussion sites, I can easily get over 25% of the requests satisfied locally -- and housemates notice the difference -- especially on things like heavily thumbnail'd sites like youtube.
Think twice about https everywhere, as it ends up with the standard being that gateway owners (companies or individuals) need to install ways to overcome that.
That harms "sensitive-sites" that really should use https, (finance, medical, etc).
IT sounds like you need to MITM the HTTPS connection with your proxy. I was under the impression that this has been SOP in business for a while, especially since you can re-sign the certs and force the trust down on the client machines using built-in Windows AD tools.
You said "housemates" I assuming you don't have more than 3-4? shouldn't be too big a deal to install your cert onto their devices then MITM everyone's connection so you can continue mining their social media passwords :P
new owners, and they stopped that a long while ago.
The trust has been broken. I won't use a sourceforge project.
One of mine gets hundreds of downloads a week. There are other people.
I love how I can organize binary releases, on sourceforge, vs what on github?
That's what I meant by https "everywhere" harming security for those sites that have a legitimate need for it. By implementing a MITM proxy, it makes all https streams less secure. I don't like that trade-off (not that I don't already have such
implemented for myself).
At the same time, google is pushing for "certificate transparency"
(https://www.certificate-transparency.org/what-is-ct ), that might not let home-user issued certs be used for such purposes --- not sure. The more internal-proxies that implement MITM HTTPS for their internal needs/wants, the more pressure
those not wanting those streams to be easily visible or cacheable will work to disable that "hole"... (IMNSHO)...
That's what I meant by https "everywhere" harming security for those sites that have a legitimate need for it. By implementing a MITM proxy, it makes all https streams less secure.
Cleartext HTTP: Any router on the path can see the communication.
HTTPS: Only three hosts can see the communication, namely the client, the server, and the corporate MITM.
It's still an improvement.
The more internal-proxies that implement MITM HTTPS for their internal needs/wants, the more pressure those not wanting those streams to be easily visible or cacheable will work to disable that "hole"
Are you referring to public key pinning? Native apps for smartphone-derived operating systems already do this as a common practice.
cleartext HTTP .. there are no routers on the path that aren't capable of playing MITM. What do I care if they "see" what kernel version I download or open source project I download. Who cares if they see the articles I am reading/writing on slashdot.
There is no improvement as google knows all the traffic as it tied into almost every site and HTTPS doesn't help a bit. And they in turn can hand the info over to any gov agency that asks for it -- and be forced not to tell you about it.
HTTPS is a wet-security blanket.
public key pinning? No -- you can intercept the traffic at the ISP level -- I'm sure larger ISP's can get a root-cert. When you connect to an encrypted site, you really connect to your ISP's pass-through traffic decoder, which then passes another encrypted circuit on to wherever you were going.
HTTPS safety is an "illusion" to get you to use it so you can't easily be selective about what you block or cache by site.
Caching rate on HTTP sites -- 10-30 or higher %, on HTTPS -- 0%, and there's the overhead of encrypting.
When you connect to an encrypted site, you really connect to your ISP's pass-through traffic decoder, which then passes another encrypted circuit on to wherever you were going.
That's true only if your ISP is using an intercepting proxy. Because the proxy's internal CA is not installed as a trusted root on a stock client, a stock client will display an "untrusted issuer" warning. So I imagine that networks serving only a minority of clients, such as corporate or school networks or ISPs in less-developed economies, would force an intercepting proxy on clients newly introduced to the network.
HTTPS safety is an "illusion" to get you to use it so you can't easily be selective about what you block or cache by site.
Blocking "by site" is still possible with HTTPS, as the Server Name Indication (SNI) field of the TLS ClientHello message contains the hostname in cleartext so that the server can know which virtual host's certificate to present. Intermediate caching or blocking at a finer level than "by site" does require MITM though.
Caching rate on HTTP sites -- 10-30 or higher %, on HTTPS -- 0%
Are you referring to caching on the client or caching on intermediate proxies? Clients cache HTTPS the same way they cache cleartext HTTP. Intercepting proxies cache HTTPS only if the user has chosen to trust the proxy.
> That's true only if your ISP is using an intercepting proxy.
---
Right -- they are a large corporation. You don't think they couldn't be ordered to do so and say nothing under the Patriot act? Do you disbelieve that root-ca's in the US or other monitoring countries couldn't be forced to give out subordinated CA's to install @ ISP monitoring sites?
> Blocking "by site" is still possible with HTTPS...blocking at a finer level than "by
> site" or "intermediate caching" still requires MITM.
I've always blocked by site and media type and for any unclarities, I looked at the http code. That's no longer possible unless a user sets up MITM proxying that
lowers security for all https sites (finance, et al.). While I can install exceptions to
whitelist sites that shouldn't have content cached, they are still decrypted.
One has to know content type and size to effectively cache anything. Right now, going back for the past 3500 requests, I see stats of:
(mem = in-squid-memory)
mem: 8% (313/3514), 16% (11M/70M)
dsk: 23% (842/3514), 10% (7.2M/70M)
tot: 32% (1155/3514), 26% (19M/70M)
& for double that:
mem: 5% (367/7025), 9% (12M/126M)
dsk: 21% (1523/7025), 14% (18M/126M)
tot: 26% (1890/7025), 23% (29M/126M)
---
without MITM caching, those numbers drop to near 0 for HTTPS sites. Those cached objects serve for multiple browsers, OS's, machines and users. Losing ability to cache 25-30% hurts interactive use and raises latency. Simply by going w/HTTPS instead of HTTP creates increased server load and increased network latencies. Sites that provide many static images can be affected more heavily. But my local network cache provides 128G of space (55% used) and can store large iso images that can be reserved months later. W/my monthly traffic, 25% space savings can easily run in the 500G range which is, by itself,
well over many ISP imposed limits before extra charges kick in.
> Intercepting proxies cache HTTPS only if the user has chosen to trust the proxy.
----
Which is why converting most traffic to HTTPS instead of HTTP hurts caching proxies the most and allow easier tracking by sites like google. From the time I connect to some sites, till I leave, google, et al, have encrypted connections
going. They can easily track sites and where I'm at on the site, w/o doing any special MITM interceptions using fed-provided CA's from US-based CA-authorities.
My interest has been in promoting faster browsing experience (something I've had success in, given feedback from those using the MITM proxies), as well as increasing privacy by blocking sites based on what sites they are being called or referenced from. You can't do that if the site you are connecting to is HTTPS based.
I see no benefit for HTTPS for "normal usage" -- only harm for the user and benefits for the sites -- especially large, data collection sites like google.
Do you disbelieve that root-ca's in the US or other monitoring countries couldn't be forced to give out subordinated CA's to install @ ISP monitoring sites?
That's what "certificate transparency" is supposed to block.
MITM proxying that lowers security for all https sites (finance, et al.).
The problem might be related to the historic use of the scheme and port as a hint for whether or not it ought to be possible to treat a particular connection as Cache-Control: public or not. I'll have to think about how to most effectively express this problem to "encrypt all the things" types.
Simply by going w/HTTPS instead of HTTP creates increased server load and increased network latencies.
There are anecdotal reports that HTTP/2 over TLS can have less latency than cleartext HTTP/1.1. So if you add HTTP/2 to your MITM, you may be able to mitigate some of the TLS overhead.
From the time I connect to some sites, till I leave, google, et al, have encrypted connections going.
A hosts file or client-side tracking blocker extension works for HTTPS just as well as for cleartext HTTP.
> hosts file or client-side tracking blocker extension works for HTTPS
> just as well as for cleartext HTTP.
---
You can't use a hosts file to selectively block content. I've already stated, that to cache or to block, you need to know the object-type and size. You don't get that w/HTTPS.
> There are anecdotal reports that HTTP/2 over TLS can have less latency
> than cleartext HTTP/1.1. So if you add HTTP/2 to your MITM, you may be
> able to mitigate some of the TLS overhead.
---
Interesting, but it would be highly dependent on type of traffic. HTTP/2 was supposed to help response time by combining multiple requests, including allowing for combining requests from divers sources, so it would be unsurprising if it worked under some traffic loads. This is especially true compared to uncached cleartext.
However, I doubt HTTP2 proponents would be interested in doing benchmarks where 33% of the cleartext HTTP requests had 0 latency due to being locally cached.
Maybe it goes w/o saying, but combining the requests is the opposite of what would be necessary to block or locally cache 33% of the content.
If you want to selectively block media types, you can do that using a browser extension installed on each PC. Or you can set up a proxy on localhost on each PC and have the browser installed on that PC trust that proxy's root certificate. Then you're back down to two parties being able to see the communication: the client and the localhost proxy, and the server. This regains blocking by media type but loses a shared cache.
It's also possible to configure your Squid proxy to behave differently on sites that are unusually privacy-sensitive using a stare rule. Log the SNI field of each ClientHello message from your proxy's clients. Build a list of which hostnames ought to be cached (high-traffic sites) or not (financial or medical sites), and be transparent with your users about the process of building this list. Bump (MITM) the high-traffic sites so that you can cache them, and splice (tunnel) the sensitive ones so that you can reassure users that your proxy isn't snooping this particular connection. The user will be able to tell whether a connection is through your proxy by looking at who issued the certificate. For example, in Firefox, one can click the lock in the URL bar, click the right arrow, and read "Verified by:".
On the other hand, see replies to bigjosh on Coding Horror Discourse, who expressed the same need for caching. One of the replies expresses a possibility that the fact of having read articles about a particular subject on Wikipedia might itself be sensitive even if Wikipedia is public and cacheable.