From: muta...@gmail.com   
      
   On Friday, June 18, 2021 at 6:14:03 AM UTC+10, Grant Taylor wrote:   
      
   > > Depending on the exact use case, people may not care about having   
   > > hackers with the ability to intercept traffic to be able to decrypt   
   > > their communication.   
      
   > Or they may care about security but care about actually being able to   
   > accomplish the task at hand /more/ than they care about security.   
      
   Good way of putting it.   
      
   > > TLS 1.0 means that the "glorified telephone people" need to go to   
   > > some effort to see my passwords, and may lose their jobs if they are   
   > > caught. Sounds good to me.   
      
   > I tend to refer to that as "preventing casual snooping". As in "I   
   > wonder what the packet sniffer will show me today." type thing.   
      
   Another good way of putting it.   
      
   > > The browser people seem to be in a conspiracy to prevent people from   
   > > accessing a TLS 1.0 server, even internally within a company.   
      
   > It's not /just/ a conspiracy (theory). There are legitimate security   
   > problems with SSL and earlier versions of TLS. It's just that fairly   
   > small number of people are actually impacted by the security problems.   
   > I suspect that more people are adversely impacted by removing older SSL   
   > / TLS support than are actually impacted by the vulnerabilities therein.   
      
   Yeah.   
      
   > > Sounds to me like there's a market for a rival browser that enables   
   > > the use of TLS 1.0, perhaps with a warning.   
      
   > I would argue against creating a rival browser. The browser space is   
   > already suffering and sliding towards a mono-couture (Chrome). I think   
   > you would be better off forking an existing browser and re-enabling the   
   > code to support old SSL / TLS.   
      
   I don't understand this comment. Do you mean fork an   
   existing browser that isn't Chromium-based?   
      
   And you don't seem to like this slide and suffering, while   
   at the same time I shouldn't create a rival to all this?   
      
   > The other thing that you can look at is something like Squid as an SSL /   
   > TLS proxy that translates between SSL / TLS versions on either side.   
   > I'm actually going to be doing this for various reasons in the near future.   
      
   Ok, thanks for the pointer.   
      
   > > Maybe I can start from scratch with a simple browser.   
      
   > Please don't.   
      
   The trouble is that the system I am most interested in is   
   PDOS/386 which only supports C90. Well, sort of.   
      
   I want to flesh out what is possible with C90.   
      
   What existing C90 browser do you suggest I use instead   
   of creating my own? Preferably one that is public domain.   
      
   > > And offload the OpenSSL code (I assume there is no public domain   
   > > code available to do this, so this is the best I can do) to my   
   > > virtual modem.   
      
   > Moving the OpenSSL code (et al.) from the computer to the modem doesn't   
   > actually change anything about the problem you're talking about. If   
   > anything, it's potentially going to complicate things, or make them   
   > harder to maintain.   
      
   Moving OpenSSL code to the modem means that my OS   
   is uncomplicated.   
      
   I don't really give a shit about how crappy the modem is.   
   It can do forks and TCP/IP and ioctl and TLS etc.   
      
   All I want is my modem back. I never agreed to give it up.   
   Or the attached BBS software.   
      
   People are invalidating my software and my knowledge.   
   If I choose to learn new stuff, I wish to do it at my own   
   pace. In the meantime I am perfectly happy writing C90   
   code to control a modem. I do expect the modem to be   
   faster and cheaper, and making use of fiber instead of   
   copper. But all this should be transparent. At least if I   
   follow the rules, and even if the rules are only apparent   
   in hindsight. Namely:   
      
   1. Apps should fopen COM1 or preferably a user-defined   
   string to get access to the modem, which may not   
   necessarily use "ATDT" to dial, so let the OS take care of   
   that.   
      
   2. The OS should use INT 14H to get access to the serial   
   port. Yes, it's slower and crappier than direct hardware   
   access, but it future-proofs your OS.   
      
   3. The BIOS may be configurable to let INT 14H read block   
   or timeout, so the OS should be able to cope with a timeout   
   and hard loop if desired.   
      
   BFN. Paul.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)