Re: [Lynx-dev] TLS-"transport layer security" & LYNX
David Woolley dixit: > Because the request URI hasn't been sent at the time that the > appropriate certificate for the host needs to be selected. It is only > sent after encryption is established, based on that host name. Yes, but I showed no less than three ways to deal with that problem in a less privacy-reducing way. And *forcing* clients to use SNI instead of merely accepting it is way out of proportions. > Although the average web consumer doesn't seem to understand it, knowing Note that there’s more to the internet than the web, by the way. > Even without the host being in clear text, there are quite a lot of side > channels that could be used to make a good guess as to which page on an > a server is actually being accessed, in particular checking the length > of the response. That may be so, but there are counter-measures for those, especially if the sheer amount of available pages makes that untenable. The existence of other side channels is no excuse to not plug this one, or rather, to open it in the first place. And yes, I see this pretty absolutely. bye, //mirabilos -- Yes, I hate users and I want them to suffer. -- Marco d'Itri on gmane.linux.debian.devel.general ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] TLS-"transport layer security" & LYNX
On 28/07/18 23:39, Travis Siegel wrote: I thought the whole reason httpd 1.1 was produced was specifically for this reason. Why do they need multiple methods of producing the same result, especially when one breaks existing standards? Because the request URI hasn't been sent at the time that the appropriate certificate for the host needs to be selected. It is only sent after encryption is established, based on that host name. Although the average web consumer doesn't seem to understand it, knowing that you are talking to the intended host is critical to secure sockets being truly secure. Without that, you are vulnerable to a man in the middle attack. Even without the host being in clear text, there are quite a lot of side channels that could be used to make a good guess as to which page on an a server is actually being accessed, in particular checking the length of the response. ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] TLS-"transport layer security" & LYNX
I thought the whole reason httpd 1.1 was produced was specifically for this reason. Why do they need multiple methods of producing the same result, especially when one breaks existing standards? On Sat, 28 Jul 2018, Mouse wrote: SNI basically transmits the actual vhost you wish to visit, in URL terms the part between https:// and the first slash after that, [...] [...] Then, the people [...] thought it would be good to create TLSv1.3 [...] and decided to add SNI to that standard; not only that, but they *require* it to be used now. So, TLS 1.3 is not usable for securing anything except the Web? (That is, if you aren't "visit"ing a "vhost"?) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] TLS-"transport layer security" & LYNX
Mouse wrote in <201807281950.paa01...@stone.rodents-montreal.org>: |> SNI basically transmits the actual vhost you wish to visit, in URL |> terms the part between https:// and the first slash after that, [...] |> [...] |> Then, the people [...] thought it would be good to create TLSv1.3 |> [...] and decided to add SNI to that standard; not only that, but |> they *require* it to be used now. | |So, TLS 1.3 is not usable for securing anything except the Web? (That |is, if you aren't "visit"ing a "vhost"?) For example RFC 7672[1], 8.1. "SNI Support" To ensure that the server sends the right certificate chain, the SMTP client MUST send the TLS SNI extension containing the TLSA base domain. This precludes the use of the Secure Socket Layer (SSL) HELLO that is SSL 2.0 compatible by the SMTP client. Each SMTP server MUST present a certificate chain (see [RFC5246], Section 7.4.2) that matches at least one of the TLSA records. The server MAY rely on SNI to determine which certificate chain to present to the client. Clients that don't send SNI information may not see the expected certificate chain. [1] https://tools.ietf.org/rfc/rfc7672.txt --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] TLS-"transport layer security" & LYNX
> SNI basically transmits the actual vhost you wish to visit, in URL > terms the part between https:// and the first slash after that, [...] > [...] > Then, the people [...] thought it would be good to create TLSv1.3 > [...] and decided to add SNI to that standard; not only that, but > they *require* it to be used now. So, TLS 1.3 is not usable for securing anything except the Web? (That is, if you aren't "visit"ing a "vhost"?) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] recognition in the 'New York Times'
russellb...@gmail.com dixit: > tech...@nytimes.com It's your tip. They use Googlemail, I cannot reliably communicate with them because Google ignores basic Internet standards and best practices and thinks they can get away with it (“too big to fail”). Please do forward this discussion there. Thanks, //mirabilos -- Stéphane, I actually don’t block Googlemail, they’re just too utterly stupid to successfully deliver to me (or anyone else using Greylisting and not whitelisting their ranges). Same for a few other providers such as Hotmail. Some spammers (Yahoo) I do block. ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] TLS-"transport layer security" & LYNX
David Niklas dixit: >All that being said, I'd be interested in knowing what Thorsten Glaser >was talking about with respect to TLS 1.3. I though, perhaps somewhat >naively, that all headers, cookies, and the resource(s) you are That used to be true. Then, people who wanted to host multiple sites on one physical server started to listen to Apache webserver warnings that “having multiple vhosts on one SSL port does not work” (when it works very well, if you have a wildcard or multi-sAN cert) and decided to create an extension to SSL/TLS, called SNI (server name indication), which made its way into OpenSSL 0.9.8 and up. SNI basically transmits the actual vhost you wish to visit, in URL terms the part between https:// and the first slash after that, in plaintext to the server BEFORE SSL is established so the server can choose the “correct” certificate for that domain. This is all to silence webserver and webbrowser warnings, when a number of different ways would have worked too: • for site1.example.com and site2.example.com, use a wildcard certificate for *.example.com instead • for site1.example.com and site2.example.org, use a multi-sAN certificate instead which has subjectAltName contain both DNS:site1.example.com and DNS:site2.example.org attributes • or just use IPv6 and have site1 use IP address 2001:db8::1 and site2 use 2001:db8::2, so you don’t even need vhosts at all This extension was optional for a long time, but more and more sites have started implementing it, including, unfortunately, community-driven projects such as Debian, citing it being a “standard”. (It’s probably been in some RFC.) After some time, we arrived at TLSv1.2 (OpenSSL 1.x) being in widespread use, more cryptographic problems showing up and being solved (incidentally most of them only applying to stuff wildly added to OpenSSL 0.9.8 while those of us who stuck with 0.9.7 were unaffected by most of them and could backport the remaining fixes manually). Then, the people at some green table committee thought it would be good to create TLSv1.3 (which uses completely different ciphersuites too and perhals would better have been TLSv2.0) and decided to add SNI to that standard; not only that, but they *require* it to be used now. Instead of improving security, TLSv1.3 actually reduces privacy. It’s not the first time a standard is idiotic (one of the mandates of POSIX is actually illegal in Germany, for example); choosing to not support SNI will however have a changed outlook now: before, you could tell people to get proper wildcard/multi-sAN certificates or IPv6 instead; now they can reject that suggestion citing SNI is required by TLS, and just ignore one’s problem reports. I doubt this is the only problem with TLS, and newer TLS versions in general. (There's also quite a bit of protocol ossification: embedded systems like ADSL modems, routers, etc. that can’t upgrade will now be unable to connect to those sites requiring newer TLS versions and have to fall back to unencrypted (if at all supported) instead of using the older TLS version that still provides sufficient security unless you are a bank, if you disable a few problematic features and ciphersuites and implement a few countermeasures. Nobody cares, mostly because a conglomerate of Google and Mozilla want to force their latest adver‐ tisement-displaying-engines (aka “modern browsers”) upon you and an easy way to do that is to make the old ones stop working. Disillusioned greetings, //mirabilos -- “It is inappropriate to require that a time represented as seconds since the Epoch precisely represent the number of seconds between the referenced time and the Epoch.” -- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2 ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] TLS-"transport layer security" & LYNX
>>> [...] webservers that refuse to serve anything over HTTP except a >>> redirect to HTTPS. >> They are just following an industry trend orchestrated by Google. >> [...] >> It's difficult to get a good explanation for the policy, [...] > The reason that https is being mandated is so that everyone has > protection from the NSA and other governments and companies _That_ protection was blown when the first wildcard cert was issued - or, if you think of it another way, when support for wildcard certs was implemented. (I'm not convinced the publicly available crypto is secure against letter agencies even when used securely, for that matter, but that's a separate question, and the above stands even if it is secure.) > manipulating connections, blocking connections that are deemed > "unwanted / illegal / etc.", and spying on user agents. That's all very well, and I'm glad it's available. My beef is with webservers imposing it on clients, rather than letting clients choose. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] TLS-"transport layer security" & LYNX
On Tue, 24 Jul 2018 09:14:25 +0100 David Woolley wrote: > On 24/07/18 01:31, Mouse wrote: > > Actually, in my case, it's the fault of webservers that refuse to > > serve anything over HTTP except a redirect to HTTPS. I neither have > > nor want HTTPS support. > > > > They are just following an industry trend orchestrated by Google. In > particular, having a non-HTTPS site will result in appearing a long way > down the Google search results. Most sites are either their to sell > something, or to sell people to advertisers, so they want a good google > ranking. > > Even when the contents is the primary reason for the site, hosting > costs have to be paid, and that is often done by advertising. > > It's difficult to get a good explanation for the policy, but my guess > is that is the number of people accessing from mobile devices using > public hot spots. The reason that https is being mandated is so that everyone has protection from the NSA and other governments and companies (and I have personally, and frequently encountered all of the above, here in the US), manipulating connections, blocking connections that are deemed "unwanted / illegal / etc.", and spying on user agents. "Illegal" often has nothing to do with traditional (i.e. Christian), morality and more to do with the ruling classes desire not to face any dissension from exterior sources. Thus governments and companies are faced with the choice of either blocking the whole domain or non at all. And connection manipulation becomes impossible, but that does not stop US companies and the government from manipulating anything that is not encrypted. If a site offers both http and https then the US government will actually go as far as blocking the https version. I am referring to the US libraries here. This is not to mention the "sign on" pages that you encounter when you visit any number of "open" wifi access points. All that being said, I'd be interested in knowing what Thorsten Glaser was talking about with respect to TLS 1.3. I though, perhaps somewhat naively, that all headers, cookies, and the resource(s) you are requesting are encrypted thus nothing could be leaked / manipulated / or affected during the session. The best an adversary could do was guess what you asked for. Sincerely, David ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] recognition in the 'New York Times'
Quoth Thorsten Glaser: 'Perhaps someone can forward this data point, perhaps the entire lynx-dev discussion, to that article author?' tech...@nytimes.com It's your tip. russell bell ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] lynxing @washingtonpost.com Quoth Paul Gilmartin: 'I read WaPo with Firefox. When they pop up that I must
subscribe, I disable popups and continue reading. Perhaps they dislike lynx because their subscription form doesn't work on lynx.' That's functional. All I have to do is remove 'lynx' from the user-agent header, not subscribe. russell bell ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] recognition in the 'New York Times'
Gisle Vanem dixit: > Testing with my Opera Mini browser on my Nokia phone, the front-page size > was 236 kByte (89% reduction) thanks to "Opera Mini Mark-up Language". Yes, sure, but in this scenario you have Opera servers as a proxy (who can read all your data) instead of just your own ones. Not for the privacy-conscious, and especially not for pages where you have to actually log in. Also, as it depends on an external, third-party, service, it can cease working at any time. bye, //mirabilos (whose Nokia 6150 thankfully doesn’t do Internet) -- cool ein Ada Lovelace Google-Doodle. aber zum 197. Geburtstag? Hätten die nicht noch 3 Jahre warten können? bis dahin gibts google nicht mehr ja, könnte man meinen. wahrscheinlich ist der angekündigte welt- untergang aus dem maya-kalender die globale abschaltung von google ☺ und darum müssen die die doodles vorher noch raushauen ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] recognition in the 'New York Times'
Thorsten Glaser wrote: There’s one very great thing they missed, though. For example, the Groundspeak geocaching website used to have a page load size of over 1 MiB (HTML alone), I believe they cut a hundred or two off it by now but this is still ridiculous, yet most of the pages renders well by lynx. I didn't find the large 'Groundspeak geocaching' page you referred to. So I tested using the Norwegian news-paper https://www.vg.no (which BTW looks awful in Lynx compared to most NYT pages). www.vg.no has a front-page of 2.6 MByte (HTML only) Testing with my Opera Mini browser on my Nokia phone, the front-page size was 236 kByte (89% reduction) thanks to "Opera Mini Mark-up Language". The page started slowly, but rendered acceptable on the 37x55mm screen. Refs: https://dev.opera.com/articles/opera-binary-markup-language/ https://github.com/grawity/obml-parser -- --gv ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
