Re: [Lynx-dev] TLS-"transport layer security" & LYNX
> My grudge against HTTPS, for example, is that just looking through an > average certificate store is an enourmous set of public keys - and it > would seem to be impossible to keep up with who actually owns the > private counterparts of these. And it only takes one to be > compromised to throw everyone's HTTPS verifications off. Quite so. I would be astonished if none had leaked. But then, the whole security model was compromised the first time a TLD-wildcard cert was issued (such as is used for "captive portal" interposers by airlines for their in-flight wifi and the like) - or, if you prefer, when support for them was implemented. > But maybe one day HTTPS will be more robust, safe. Well...maybe something derived from it will be - though I have my doubts - but, if so, I think it won't be much like HTTPS any longer. > Personally I think physically going to a business and being given a > copy of their key would be good... a mix of old and new. Yes. Throw out the whole CA-chain model; it's fundamentally broken, by wildcards, by lack of transparency of the root-CA list, and by being run by businesses and therefore having (from users' point of view) perverse incentives. /~\ 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
> > > 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 idea is that if the webserver does not impose it the client will not > get the choice because of the gov./etc., thus the choice is imposed on all > for those whose clients would not get the choice. > > It is a trade off. > A little late, but, something I wanted to post here: Apparently, according to https://www.howsmyssl.com my distribution of Lynx is supporting weak cipher suites, and that is the only problem with Lynx's TLS. '3DES vulnerable to sweet32' I think this is something that can be fixed upstream? Assuming the opinions of howsmyssl.com on cipher suites are credible. Yes, I would conclude HTTPS is one big trade-off, with obvious flaws. My grudge against HTTPS, for example, is that just looking through an average certificate store is an enourmous set of public keys - and it would seem to be impossible to keep up with who actually owns the private counterparts of these. And it only takes one to be compromised to throw everyone's HTTPS verifications off. So I try to think of HTTPS as a 'public beta' - consumers have only just moved to the internet for everything over the past 10 years, and there are various developments that need to happen to it. I too dislike the power of Google, but they are introducing a new security header named 'Expect-CT' which _might_ solve the thing I most dislike about HTTPS. It should be easier to implement than HKPK. But at present the 'Secure' and 'NotSecure' notices in Chromium/Chrome are just oversimplified humour! But maybe one day HTTPS will be more robust, safe. Personally I think physically going to a business and being given a copy of their key would be good... a mix of old and new. ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] TLS-"transport layer security" & LYNX
2018/07/24 04:14 ... David Woolley: In particular, having a non-HTTPS site will result in appearing a long way down the Google search results. I try'd that with a Google-search for something local to me, "toledo lucas public library" and did not see that effect, but saw something doubtless most of you know, that every link in the answer points to Google. (I usually use Duckduckgo.) ___ 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 dixit: >Because there is no technical difference between that and a cert for >*.com or *.qc.ca: there is no way to tell, when presented with the >cert, whether everything covered by it is under common administration. Except the asterisk does not match a dot. So *.com would be valid for example.com but not www.example.com. CAs are a critical failure point anyway… I recall posting to this list a suggestion that lynx could remember server certificates, what others, a decade or so later, now call HPKP IIRC. bye, //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
>>> protection from the NSA and other governments and companies >> _That_ protection was blown when the first wildcard cert was issued > If I own example.com and I get a cert for *.example.com how is that > insecure? Because there is no technical difference between that and a cert for *.com or *.qc.ca: there is no way to tell, when presented with the cert, whether everything covered by it is under common administration. /~\ 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 Sat, 28 Jul 2018 11:53:59 -0400 (EDT) Mouse wrote: > >>> [...] 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. If I own example.com and I get a cert for *.example.com how is that insecure? I've read things like what you've wrote above before and there is always that little detail missing... > > 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 idea is that if the webserver does not impose it the client will not get the choice because of the gov./etc., thus the choice is imposed on all for those whose clients would not get the choice. It is a trade off. "The needs of the few outweigh the needs of the many." -- Star Trek, when Spock's logic got reversed to justify saving his life. Sincerely, David ___ 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 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] 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] 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. 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. Perhaps. But some sites for which I would think Google rankings are irrelevant are joining in, even - like CIRA, which goodness knows I'm no fan of but for which I have trouble seeing Google ranking as outweighing their duty to be as accessible to everyone as possible. Perhaps what you outline is most of it, and the others are just bandwagon-jumpers, or some such. /~\ 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 Jul 24, 2018, at 04:14, 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. possibly, but it is rather self serving as well forcing everyone to serve over https hid the referer in their search analytics product - this was formerly freely available for inspection it is not hidden from them of course, and they will happily sell you access to that data, for a high price there is much irony to be enjoyed as we realize that their data collection (which is ubiquitous unless you browse with lynx) occurs over “secure” protocols, essentially so it can be packaged up and sold as a premium feature in their products —stef http://smashgods.ca ___ 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 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. ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] TLS-"transport layer security" & LYNX
Thorsten Glaser wrote: > Mouse dixit: > > >> go to for my work and it gets worse daily. > > > >Me too, but it's not lynx's fault in my case. > > If it’s “getting worse daily” I suspect it’s the fault of all those > sites and CDNs now requiring TLSv1.1 or TLSv1.2 or an ECC ciphersuite. > I am hit hard by those as well. > > There’s likely no way out except upgrading to LibreSSL or something. > But that’s an OS-wide issue, nothing lynx can help you with. Indeed - we got this sorted out 'off list' by upgrading the version of openssl and building lynx against that. ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] TLS-"transport layer security" & LYNX
>>> [...] go to for my work and it gets worse daily. >> Me too, but it's not lynx's fault in my case. > If itâ??s â??getting worse dailyâ?? I suspect itâ??s the fault of all > those sites and CDNs now requiring TLSv1.1 or TLSv1.2 or an ECC > ciphersuite. I am hit hard by those as well. 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. > Thereâ??s likely no way out except upgrading to LibreSSL or > something. But thatâ??s an OS-wide issue, nothing lynx can help you > with. If lynx can't build with TLS support other than the underlying OS's, I respectfully submit that its build procedure is broken. :-) > I admit having been a proponent of using HTTPS everywhere for quite > some time, [Mini-rant alert.] That's not an unreasonable choice for clients. But for servers? Because there is no way to negotiate, to arranve that clients that are willing to switch to HTTPS do so and clients that aren't don't, I think it is unreasonable for servers to insist on it. (In general. There certainly are things for which it's reasonable.) I do nothing at all on the Web for which HTTPS is appropriate or even helpful; why should I have to pay the CPU cycle and exposed attack surface costs of HTTPS support? Yet increasingly large numbers of webservers insist on ramming HTTPS down my throat anyway. (Or, rather, trying to. Since I don't have HTTPS support, all they succeed in doing is driving me away from their pages.) > (so I now continue offering https but wonâ??t force people to use it, > except on actual login pages and such and the > confidential/user-specific data they generate). Thank you. Would that all web admins were that sane. /~\ 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
Mouse dixit: >> go to for my work and it gets worse daily. > >Me too, but it's not lynx's fault in my case. If it’s “getting worse daily” I suspect it’s the fault of all those sites and CDNs now requiring TLSv1.1 or TLSv1.2 or an ECC ciphersuite. I am hit hard by those as well. There’s likely no way out except upgrading to LibreSSL or something. But that’s an OS-wide issue, nothing lynx can help you with. I admit having been a proponent of using HTTPS everywhere for quite some time, but this nonsense (and insecurity; TLSv1.3 *mandates* SNI which leaks the actual vhost you’re addressing to eavesdroppers just because idiots can’t be arsed to use IPv6 instead of name-based vhosts or shell over enough money for wildcard or multi-sAN certificates) is more than just irritating (so I now continue offering https but won’t force people to use it, except on actual login pages and such and the confidential/user-specific data they generate). >For example, I've had some failures trying to use lynx with various >websites where all I get is a "403 Forbidden" nginx page. I don't know >what's wrong, but I see no reason to think it's lynx's fault. These don’t seem to get more. They are the site administrators’ fault, although nginx seems to ship(? have shipped once?) a default configuration that blocks “evil download bots” like lynx and GNU wget. (Just when we thought those were a thing of the past, inci‐ dentally, this started. But then, I associate nginx with those new- fangled “10x rockstar hipster developer” people, and _those_ are known to repeat the mistakes of the past, ten times worse in some cases.) bye, //mirabilos -- 21:12⎜ sogar bei opensolaris haben die von der community so ziemlich jeden mist eingebaut │ man sollte unices nich so machen das desktopuser zuviel intresse kriegen │ das macht die code base kaputt 21:13⎜ linux war früher auch mal besser :D ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] TLS-"transport layer security" & LYNX
> Hi to any of you programmers who can please fix this! > Using LYNX, I'm now shut out of more than 50% of websites I normally > go to for my work and it gets worse daily. Me too, but it's not lynx's fault in my case. What you've said is not a useful problem report. I'm not someone who would be working on this, but if I were, I would be asking for specifics like - At least a few examples of specific URLs you see failures from - What goes wrong (that is, what you expect and what you get) For example, I've had some failures trying to use lynx with various websites where all I get is a "403 Forbidden" nginx page. I don't know what's wrong, but I see no reason to think it's lynx's fault. In your case, it might or might not be lynx's fault; if it's not, it might or might not be feasible for lynx to work around the actual problem - we don't have enough information to tell. /~\ 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
Hi Larry, thanks for your rapid reply. I forwarded your email to my tech, Giles Steinberg, who can supply you with the requested info. Shel Talmy On Mon, 23 Jul 2018, Larry Hynes wrote: Shel Talmy wrote: Hi to any of you programmers who can please fix this! Using LYNX, I'm now shut out of more than 50% of websites I normally go to for my work and it gets worse daily. TLS doesn't allow LYNX to logon to any of these TLS protected websites and I'm "pleading" with you to effect a fix for LYNX ASAP. And I'm open to recommendations for a browser in UNIX that will access the sites I'm now shut out of. Yes, this is desperation time, so please tell me what I can do, as gonna assume I'm not the only one using LYNX with this problem. Hi Lynx, when configured to do so, can connect to secure websites i.e. those whose addresses begin with https:// Can you tell us, please: - The operating system that you are running lynx on (windows, linux, apple, etc.) - How you installed the version of lynx that you are running And can you put in your message, please, the output of lynx -version ___ 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 2018-07-23, at 10:57:19, Shel Talmy wrote: > > Using LYNX, I'm now shut out of more than 50% of websites I normally go to > for my work and it gets worse daily. > Now you understand why "GDPR" starts with "GD". -- gil ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
Re: [Lynx-dev] TLS-"transport layer security" & LYNX
Shel Talmy wrote: > Hi to any of you programmers who can please fix this! > > Using LYNX, I'm now shut out of more than 50% of websites I normally go to > for my work and it gets worse daily. > > TLS doesn't allow LYNX to logon to any of these TLS protected websites and > I'm "pleading" with you to effect a fix for LYNX ASAP. > > And I'm open to recommendations for a browser in UNIX that will access the > sites I'm now shut out of. Yes, this is desperation time, so please tell > me what I can do, as gonna assume I'm not the only one using LYNX with > this problem. Hi Lynx, when configured to do so, can connect to secure websites i.e. those whose addresses begin with https:// Can you tell us, please: - The operating system that you are running lynx on (windows, linux, apple, etc.) - How you installed the version of lynx that you are running And can you put in your message, please, the output of lynx -version ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
[Lynx-dev] TLS-"transport layer security" & LYNX
Hi to any of you programmers who can please fix this! Using LYNX, I'm now shut out of more than 50% of websites I normally go to for my work and it gets worse daily. TLS doesn't allow LYNX to logon to any of these TLS protected websites and I'm "pleading" with you to effect a fix for LYNX ASAP. And I'm open to recommendations for a browser in UNIX that will access the sites I'm now shut out of. Yes, this is desperation time, so please tell me what I can do, as gonna assume I'm not the only one using LYNX with this problem. Thank you, and really hope to hear from you very soon. Shel Talmy ___ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev
