Tag Archives: http

HTTP-over-QUIC to be renamed HTTP/3

Posted on by

QUIC stands for “Quick UDP Internet Connections” and is, itself, Google’s attempt at rewriting the TCP protocol as an improved technology that combines HTTP/2, TCP, UDP, and TLS (for encryption), among many other things.

Source: HTTP-over-QUIC to be renamed HTTP/3 | ZDNet

Since then, HTTP-over-QUIC support was added inside Chrome 29 and Opera 16, but also in LiteSpeed web servers. While initially, only Google’s servers supported HTTP-over-QUIC connections, this year, Facebook also started adopting the technology.

HTTP is obsolete. It’s time for the distributed, permanent web

Posted on by

IPFS is still in the alpha stages of development, so we’re calling this an experiment for now. It hasn’t replaced our existing site storage (yet). Like with any complex new technology, there’s a lot of improvements to make. But IPFS isn’t vaporware, it works right now. You can try it out on your own computer, and already can use it to help us serve and persist Neocities sites.

Source: HTTP is obsolete. It’s time for the distributed, permanent web

Hello HTTP/2, Goodbye SPDY

Posted on by

HTTP/2’s primary changes from HTTP/1.1 focus on improved performance. Some key features such as multiplexing, header compression, prioritization and protocol negotiation evolved from work done in an earlier open, but non-standard protocol named SPDY. Chrome has supported SPDY since Chrome 6, but since most of the benefits are present in HTTP/2, it’s time to say goodbye. We plan to remove support for SPDY in early 2016, and to also remove support for the TLS extension named NPN in favor of ALPN in Chrome at the same time. Server developers are strongly encouraged to move to HTTP/2 and ALPN.

via Chromium Blog: Hello HTTP/2, Goodbye SPDY.

HTTP/2.0 – The IETF is Phoning It In

Posted on by

The reason HTTP/2.0 does not improve privacy is that the big corporate backers have built their business model on top of the lack of privacy. They are very upset about NSA spying on just about everybody in the entire world, but they do not want to do anything that prevents them from doing the same thing. The proponents of HTTP/2.0 are also trying to use it as a lever for the “SSL anywhere” agenda, despite the fact that many HTTP applications have no need for, no desire for, or may even be legally banned from using encryption.

via HTTP/2.0 – The IETF is Phoning It In – ACM Queue.

History has shown overwhelmingly that if you want to change the world for the better, you should deliver good tools for making it better, not policies for making it better. I recommend that anybody with a voice in this matter turn their thumbs down on the HTTP/2.0 draft standard: It is not a good protocol and it is not even good politics.

The Cost of the “S” in HTTPS

Posted on by

 HTTPS may introduce overhead in terms of infrastructure costs, communication latency, data usage, and energy consumption. Moreover, given the opaqueness of the encrypted communication, any in-network value added services requiring visibility into application layer content, such as caches and virus scanners, become inef fective.

Via The Cost of the “S” in HTTPS

Eight Ways to Blacklist with Apache’s mod_rewrite

Posted on by

With the imminent release of the next series of (4G) blacklist articles here at Perishable Press, now is the perfect time to examine eight of the most commonly employed blacklisting methods achieved with Apache’s incredible rewrite module, mod_rewrite. In addition to facilitating site security, the techniques presented in this article will improve your understanding of the different rewrite methods available with mod_rewrite.

via Eight Ways to Blacklist with Apache\’s mod_rewrite | Perishable Press.

CSRF Still Armed And Dangerous

Posted on by

Designed to exploit the domain cookie trust model, CSRF attacks essentially take advantage of the trust the Web application has in its authenticated users, says Subu Ramanathan, principal consultant with Security Compass.

“In order to execute this attack, a user would have to navigate to a malicious website while logged into the victim Web application,” says Ramanathan. “The malicious website, being designed to attack users of the victim application, would make [requests] to complete sensitive transactions on the victim application on behalf of the user behind the scenes.”

via CSRF Still Armed And Dangerous — Dark Reading.

Irish Newspaper Collective Wants to Charge License Fees for Links

Posted on by

Note that this is not paying for an excerpt, which is not that unreasonable, or some punitive measure for the copying of an entire article. No, the NNI wants to charge for links like this, this, or this.

For those 3 links, I now have to pay the NNI 300 euros. Seriously. Apparently this group of 15 newspapers is under the impression that merely mentioning an article on one of websites is not legal; they think it is copyright infringement.

via Irish Newspaper Collective Wants to Charge License Fees for Links – The Digital Reader.

Also.  From: 2012: The year Irish newspapers tried to destroy the web

These are the prices for linking they were supplied with:

1 – 5 €300.00
6 – 10 €500.00
11 – 15 €700.00
16 – 25 €950.00
26 – 50 €1,350.00
50 + Negotiable

How to detect reverse_https backdoors

Posted on by

According to Mandiant 83% of all backdoors used by APT attackers are outgoing sessions to TCP port 80 or 443. The reason for why APT, as well as other attackers, are using these two ports is primarily because most organizations allow outgoing connections on TCP 80 as well as 443. Many organizations try to counter this by using web-proxies, which can inspect the HTTP traffic and block any malicious behavior. But TCP 443 cannot be inspected in this way since SSL relies on end-to-end encryption.

via How to detect reverse_https backdoors – NETRESEC Blog.

Well, something that many people aren’t aware of is that the initial part of an SSL session isn’t encrypted. In fact, there are some pieces of relevant information being transmitted in clear text, especially the X.509 certificate that is sent from the SSL server.

Not as SPDY as You Thought

Posted on by

Previous benchmarks tout great benefits, ranging from making pages load 2x faster to making mobile sites 23% faster using SPDY and HTTPS than over clear HTTP. However, when testing real world sites I did not see any such gains. In fact, my tests showed SPDY is only marginally faster than HTTPS and is slower than HTTP.

Why? Simply put, SPDY makes HTTP better, but for most websites, HTTP is not the bottleneck.

via Guy’s Pod » Blog Archive » Not as SPDY as You Thought.

If you’re a website owner, the first thing you should do is adjust your expectations. Switching your site to SPDY will move you forward, but it will not make your site much faster. To get the most out of SPDY, you should work to reduce the number of domains on your page, and to address other front-end bottlenecks. Doing so is a good move anyway, so you wouldn’t be wasting your time.