Forum upgrade?

[Thaddy]

You usually do not need a plugin, e.g. for chromium and edge :
- press F12
- click on the three dots ...(top right)
- go to More Tools
- In the user agent section, unselect, automatically
- choose a user agent from the dropdownlist.

Job done.

THIS WILL NOT HELP WITH THE PROTOCOLS!!!
It is just a user agent spoof, provided as an option.

This can probably done in Firefox too.

[MarkMLl]

Frankly, you are a moron if you demand for support for older  and insecure browser protocols.

Yes, but we could be looking at the opposite: a site which demands a recent version, and which fails to serve any sort of error message page when a client requests an older version... which it might be doing as an automatic attempt to upgrade an http: URL to https: .

Is there any way that this initial negotiation can be monitored? Is there any way that a site's requirement can be queried?

MarkMLl

[MarkMLl]

But the User Agent string in the server logs can be trivially spoofed by e.g. a browser plugin.

Sure, but in this particular instance, that is not likely to be a huge concern.  At the very least, it would be helpful info for someone on the backend, even if not accurate -- just as long as it is consistent.

What I mean is that the standard server logging (i.e. from Apache or whatever) is unreliable: it has to be something deeper which will almost certainly require Javascript.

The one thing that I'll say in Javascript's favour is that since it tends to be fairly tolerant of syntax errors it's possible to report its version and DOM etc. capabilities to a server.

That same tolerance does, of course, make it deeply suspect for any application area which aspires to be robust; and no fancy framework or toolset will improve that.

MarkMLl

[Joanna]

People keep promising that the latest greatest software is some sort of panacea that’s going to keep us all safe!  Then later it is discovered that the only thing that is getting better is the ability to spy upon people and collect analytics.

[Thaddy]

Most crypto regarding ssl/tls in done while negotiating the connection and is negotiated by the server, that offers the highest protocol first, then offers older versions downwards, then fails if it can not support that very old protocol (ssl,ssl2,ssl3,tls1.0, 1.1 for now).
Modern client software, not only browsers, will always fail with the above insecure protocols because the server will not accept a handshake. Simple.
See the comparison on wikipedia that I posted.

[MarkMLl]

People keep promising that the latest greatest software is some sort of panacea that’s going to keep us all safe!  Then later it is discovered that the only thing that is getting better is the ability to spy upon people and collect analytics.

Joanna, I admire you: you're even more paranoid than I am.

The problem is that there's at least two things involved here. The first is the underlying capabilities: improvements in cryptography etc. The second is changes (I'm carefully not saying improvements) to browsers and to the DOM, which can be exploited by remotely-loaded scripting.

And even in the second of those there are multiple aspects: behaviour which is unintended (at least by the browser and OS writers) such as a "social media" script installing malware which gets at your banking details, and "business as usual" including tracking as you move between "social media" and commerce sites.

Unintended behaviour will normally be fixed by upgrades as soon as the educated public becomes aware of it. So flatly refusing to upgrade is really not in a user's interest.

MarkMLl

[MarkMLl]

See the comparison on wikipedia that I posted.

Thanks, I'll make a point of it. But until then: is it possible to fire some sort of query at Gitlab to find out what they're prepared to accept (a bit like media encoding headers), or can that only be inferred by looking at failing browser versions?

MarkMLl

[Thaddy]

What Joanna - and the lot that do not understand protocols - can do is set up a reverse proxy, written in fpc of course, using e.g. a recent version of  fcl-net, that provides the more modern crypto and forwards it locally through, encrypted with  a deprecated protocol. If one wants to do that is a dubious question, but that would work  Alas.. And it is not easy, because you need to handle two different (versions) crypto libs.
You will need a current (trunk) version of fcl-net. And - in this case - requires the modern cryptolibs installed in the directory of the reverse proxy. (which I told everyone to never do, but this is an emergency, it seems... ) This works, because the old browser will pick up its own deprecated versions of the crypto libs.
Plz note that fcl-net versions before fpc 3.0.4 handled handshakes in the wrong order, but that is fixed after a bug report by me.

[MarkMLl]

What Joanna -  - can do

...is pretty pitiful from past experience.

However, I'm making a bit of useful progress here. Using Iceweasel 3.0.6 (which is Debian's rebranding, and I believe was basically Firefox 3.0.6) from Debian 5.0.10 ("Lenny") on an old laptop with a 1024x768 screen, when I try to go to the Gitlabs signon screen I get an explicit "ssl_error_no_cypher_overlap" error. it doesn't explicitly tell me what the server requires and what the browser is prepared to offer: (@Thaddy or anybody) can I mine that from system libraries?

I'd also observe that even with Javascript disabled I don't see a blank screen: depending on exactly what I'm doing there's either an error message or a framework with (what looks like) unpopulated frames.

I've got some newer systems I could try as well, and will do so if there is any interest.

Updated: https://hackaday.com/2022/03/22/wireshark-https-decryption/ might be relevant, since looking at the original images the Wireshark screen does show TLS version.

MarkMLl

[Joanna]

I will be the first to admit that there is a lot that I don’t know about computing.... but there is something I do know and that is things that are well designed do not need constant emergency upgrades.

The idea of things evolving and improving over time is all fine and good however it should only be necessary for obtaining more features. Things that were working before should NOT stop working because some third party decided to change something. This is what bothers me the most about so called modern computing.

[MarkMLl]

The idea of things evolving and improving over time is all fine and good however it should only be necessary for obtaining more features. Things that were working before should NOT stop working because some third party decided to change something. This is what bothers me the most about so called modern computing.

Yes, there we agree and I've seen some pretty egregious cases.

OK you have a point but what it boils down to is this: are the library maintainers entitled to say "we've been warning people for several years that there's a problem here and that Something Has To Be Done, so we've now reached the point where we're going to refuse to negotiate the older protocols".

I had to contend with something similar when I was logging into the old laptop earlier (using SSH, so that I could have a convenient text file from which I could C&P the password etc.), the difference being that I worked out the details and requisite workarounds some years ago (and that SSH can accommodate this to some extent).

The problem that the rest of us are having to deal with here is that since you flatly refuse to tell us what you're running there's no way that we can research whether there is some sort of hidden setting which would allow you to throw caution to the winds and login to remote sites- possibly via a MITM malefactor- with wanton abandon. And your refusal is based on the assumption that the fewer people who know what you're running the better: that's called "security by obscurity" and is very rarely a safe course of action.

MarkMLl

[Remy Lebeau]

Wow, this thread got out of control really quickly.  Sorry I posted my thoughts.  I'm out.  Peace!

[MarkMLl]

Wow, this thread got out of control really quickly.  Sorry I posted my thoughts.  I'm out.  Peace!

Sorry :-/

MarkMLl