TLS 1.0

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.

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.

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.

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.

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.

Maybe I can start from scratch with a simple browser.

Please don't.

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.

--
Grant. . . .
unix || die

muta...@gmail.com

2021-06-17 21:48:02 UTC

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.

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 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?

Post by Grant Taylor
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 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.

Joe Monk

2021-06-17 21:56:34 UTC

Post by Grant Taylor
I think
you would be better off forking an existing browser and re-enabling the
code to support old SSL / TLS.

We're far past those days. Most of that code has been removed from the browsers.

Also, you can no longer get an SSL cert for more than 1 year, since September of last year.

https://www.greengeeks.com/blog/ssl-tls-certificate-validity-one-year/

Joe

Joe Monk

2021-06-17 22:04:03 UTC

Oh and its also a mandate from the payment card folks...

https://www.thesslstore.com/blog/june-30-to-disable-tls-1-0/

Joe

Grant Taylor

2021-06-18 04:29:54 UTC

I don't understand this comment. Do you mean fork an existing browser
that isn't Chromium-based?

I would rather you contribute to an existing open source browser. My
pesronal preference would be something other than Chrom. IMHO there are
enough people working on Chrome and other browsers could use some help.

Especially if your efforts can be contributed to a larger project where
your specific desires could be enabled via compile time option.

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?

Modern web browsers are extremely complex, especially when considering
contemporary cryptography and security. I would prefer to avoid
fracturing efforts further.

The trouble is that the system I am most interested in is PDOS/386
which only supports C90. Well, sort of.

Either it does, or it does not.

How is an operating system the limiting factor of what level of C is
supported? Shouldn't that be the compiler's job?

I want to flesh out what is possible with C90.

You're free to impose your own artificial restrictions.

What existing C90 browser do you suggest I use instead of creating
my own? Preferably one that is public domain.

I have no idea what falls within your artificial self imposed restriction.

I'm quite certain that there's source code for Netscape from the '90s
available on various Linux archives. I'm confident that there is source
code for other browsers.

Moving OpenSSL code to the modem means that my OS is uncomplicated.

You're committing multiple layering violations for a very questionable idea.

Why don't you stick with a simple computer and a standard modem and move
all the intelligence into the serial cable. }:-) Or better yet, the
phone line.

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.

How is a modem going to do a fork?

Even if the modem could do a fork, how is the directly attached computer
or the computer at the other end going to deal with what was magical forked?

All I want is my modem back. I never agreed to give it up. Or the
attached BBS software.

What do you mean "want is my modem back"? I don't recall anyone taking
your modem from you.

People are invalidating my software and my knowledge.

Your more recent ideas have been further and further out there. Some so
far out there that I question what bases them in reality.

If I choose to learn new stuff, I wish to do it at my own pace.

Part of learning things that are new to you is understanding why others
think something can or can't be done, or should or shouldn't be done.

E.g. even if your modem can magically fork and change what it's doing,
how are the computers connected to it, one via serial and the other via
phone, going to change what they are doing to be in sync with the
modem's change?

Could something like that be done? Probably. Does anything even
remotely like that exist today? Not that I'm aware of. -- My
ignorance of such does not preclude it from existing. -- So you are
going to need to deal with the software component on both sides of the
modem in addition to dealing with the modem.

Similarly, your idea of moving OpenSSL into the modem, how are you going
to communicate all of the parameters that are used to establish SSL /
TLS connections to the modem? How are you going to provide the trusted
root certificate store? Modem's don't have any storage to speak of
(NVRAM is miniscule) and /etc/ssl on my modern system is about half a
MB. How do you manage that certificate store on the modem?

How does the OpenSSL on the modem initiate a TCP/IP connection when
modem's don't speak TCP/IP. Or are you throwing that in too?

These are some of your more recent ... ideas. Can they be done?
Theoretically, I suppose. People like to say that with enough time and
money anything is possible. But how practical is it that something can
be done or that you as a single person can do it.

The more that you talk about your modem, the more that I think of the
3172 / 3174 communications controller from IBM. The thing is that it
did some of the things you mention, but the ironic part is it used
external modems.

In the meantime I am perfectly happy writing C90 code to control a
modem.

I don't see anything at all wrong with that. More power to you and your
C90 code.

I do expect the modem to be faster and cheaper, and making use of
fiber instead of copper.

See, that's one of those things that seems ... out there. You have
stated that the modem is virtual. Now you are talking as if it is physical.

I admit that the term "modem" can mean a few different things;
historically, serial / PSTN, and more contemporary Ethernet /
{DSL,DOCSIS}. I'm somewhat at a loss for how a PSTN modem could use
fiber unless you are going to get into OC... but good luck with that.
It definitely won't be cheap in any sense of the word.

A dial-up PSTN based modem can't really go any faster than about ~30
kbps (line rate) because of problems encoding data. Problems as in you
need to sample the line at least twice as fast as the signal you want to
send through it to have any hope of getting things to work. The 33.6 ~
56 kbps (serial rate) was data compression applied to the serial stream
to shrink it down to the ~30 kbps (line rate). So ... how are you going
to make a dial up modem faster than physics can allow?

Even if you're talking Ethernet / {DSL,DOCSIS}, you are still limited to
what the {DSL,DOCSIS} network can carry.

So ... what is going to be faster about your modem?

But all this should be transparent. At least if I follow the rules,
1. Apps should fopen COM1 or preferably a user-defined string to get
access to the modem,...

What might the user defined string be? Or more importantly, what might
it represent? What significance does what it represents have?

...which may not necessarily use "ATDT" to dial,...

Okay....

...so let the OS take care of that.

Wait a minute. You have been saying that you wanted the modem to take
care of this. Now you are wanting the OS to take care of this. Which
is it? If it's now the OS and no longer the modem, why the change?

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.

I don't care how the OS accesses the serial port.

I doubt that relying on INT 14H will actually future-proof the OS. If
anything, I expect that it will future-harm the OS. -- See the recent
discussions about BIOS support. -- I believe relying on INT 14H will
effectively limit your solution to legacy systems that still support BIOS.

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.

That sounds like intelligence being put into the program / OS, which
seems to be contrary to why I thought you were wanting to put as much as
possible into the modem.

--
Grant. . . .
unix || die

muta...@gmail.com

2021-06-18 05:41:59 UTC

The trouble is that the system I am most interested in is PDOS/386
which only supports C90. Well, sort of.

Either it does, or it does not.

You can link against my kernel32.a and have functions
to create directories and a little bit more.

It is only if you link only against msvcrt.a that you are
restricted to pure C90.

Post by Grant Taylor
How is an operating system the limiting factor of what level of C is
supported? Shouldn't that be the compiler's job?

The C standards include libraries, and PDPCLIB has
straight C90, no extensions.

Yes, there's nothing preventing you from using GCC
language extensions that don't require library changes.

I want to flesh out what is possible with C90.

You're free to impose your own artificial restrictions.

When I have exhausted what is possible with C90,
I will consider relaxing those restrictions.

Up till now, C90 has covered everything I want to do.
You just need to rework your problem to fit the
paradigm.

What existing C90 browser do you suggest I use instead of creating
my own? Preferably one that is public domain.

I have no idea what falls within your artificial self imposed restriction.

It is others who created artificial self-imposed restrictions
on their code.

Post by Grant Taylor
I'm quite certain that there's source code for Netscape from the '90s
available on various Linux archives. I'm confident that there is source
code for other browsers.

And I'm pretty sure it's all going to be wall-to-wall copyrighted.
And if it isn't, it's going to be non-C90.

Moving OpenSSL code to the modem means that my OS is uncomplicated.

You're committing multiple layering violations for a very questionable idea.

This "layering" seems to be doing more harm than good.

Post by Grant Taylor
Why don't you stick with a simple computer and a standard modem and move
all the intelligence into the serial cable. }:-) Or better yet, the
phone line.

So long as I am satisfied with the design of the OS, I
don't care if there are bees and antelopes chomping
away at the copper wire to make it work.

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.

How is a modem going to do a fork?

The modem is going to look identical to a Windows
computer with Cygwin installed.

Because it is going to be a Windows computer with
Cygwin installed.

Cygwin supports fork().

Post by Grant Taylor
Even if the modem could do a fork, how is the directly attached computer
or the computer at the other end going to deal with what was magical forked?

It was just an internal implementation possibility. I don't mind
downloading some pre-existing code and running it under
Cygwin.

I already have a virtual modem, and it is already dependent
on Cygwin.

All I want is my modem back. I never agreed to give it up. Or the
attached BBS software.

What do you mean "want is my modem back"? I don't recall anyone taking
your modem from you.

Telstra even ripped up the copper wire. You have no
choice but to use fiber or 3G.

So long as I have something on the end of INT 14H that
replies "OK", I don't care.

If I choose to learn new stuff, I wish to do it at my own pace.

Part of learning things that are new to you is understanding why others
think something can or can't be done, or should or shouldn't be done.

I post here to hear exactly those things. Otherwise I would
just go ahead and code the first thing that comes to my mind.

Post by Grant Taylor
E.g. even if your modem can magically fork and change what it's doing,
how are the computers connected to it, one via serial and the other via
phone, going to change what they are doing to be in sync with the
modem's change?

I had assumed that a "virtual modem" didn't entail a physical
phone line.

Post by Grant Taylor
Similarly, your idea of moving OpenSSL into the modem, how are you going
to communicate all of the parameters that are used to establish SSL /
TLS connections to the modem? How are you going to provide the trusted
root certificate store? Modem's don't have any storage to speak of
(NVRAM is miniscule) and /etc/ssl on my modern system is about half a
MB. How do you manage that certificate store on the modem?

I have no knowledge of certificates, but I assume Windows
has a way of doing that, and the virtual modem will be
running under Windows or Linux or BSD or MacOS.

Post by Grant Taylor
How does the OpenSSL on the modem initiate a TCP/IP connection when
modem's don't speak TCP/IP. Or are you throwing that in too?

Yes, I'm throwing that in too.

One day someone may produce a physical modem that
meets the above criteria and that is the size of a matchbox,
but until then, it will look exactly the size of a PC.

Post by Grant Taylor
These are some of your more recent ... ideas. Can they be done?
Theoretically, I suppose. People like to say that with enough time and
money anything is possible. But how practical is it that something can
be done or that you as a single person can do it.

I kludge things so that I can prove the concept in my
lifetime, and developing a matchbox-sized equivalent
is someone else's job.

I do expect the modem to be faster and cheaper, and making use of
fiber instead of copper.

See, that's one of those things that seems ... out there. You have
stated that the modem is virtual. Now you are talking as if it is physical.

Virtual anything still needs something physical, like RAM.
I need bluetooth or fiber or something in order to do any
sort of communication.

Post by Grant Taylor
to shrink it down to the ~30 kbps (line rate). So ... how are you going
to make a dial up modem faster than physics can allow?

Believe it or not, even fiber can respond to "ATDE" with "CONNECT".
I'm not going to personally inspect the other end of INT 14H and
insist that it is made of copper, not fiber.

Post by Grant Taylor
So ... what is going to be faster about your modem?

100 Mbps.

But all this should be transparent. At least if I follow the rules,
1. Apps should fopen COM1 or preferably a user-defined string to get
access to the modem,...

What might the user defined string be? Or more importantly, what might
it represent? What significance does what it represents have?

ATDAnntp://eternal-september.org

(I will need that "A" if dialing from my EBCDIC system)

...so let the OS take care of that.

In config.sys I can have:

NETWORK=COM1,ATD

meaning a simple fopen of nntp://eternal-september.org will
do an INT 14H to port 0 and send an ATDA followed by the
destination I am interested in.

I might have another config file ebcdic_hosts.cfg which, if
the filename in fopen is in that list, an ATDE is issued instead.

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.

I don't care how the OS accesses the serial port.
I doubt that relying on INT 14H will actually future-proof the OS. If

It should have. That was the defined interface.

Post by Grant Taylor
anything, I expect that it will future-harm the OS. -- See the recent
discussions about BIOS support. -- I believe relying on INT 14H will
effectively limit your solution to legacy systems that still support BIOS.

If manufacturers insisted that I need to call INT 14H in
protected mode, I can live with that. But that's the
interface. That's what should exist. Those are my user
requirements. And I'll zap the firmware to get them. Or
carpet-bomb Taiwan. Whatever is easiest.

My user requirements are that manufacturers should
continue to support the interface that they provided,
unless modern computers don't have enough CPU
power to do so, because we ran out of silicon.

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.

That sounds like intelligence being put into the program / OS, which
seems to be contrary to why I thought you were wanting to put as much as
possible into the modem.

Well, the manufacturers already said (one way or another)
that INT 14H will time out instead of blocking. They defined
that interface, so I coded to that interface.

But if I have a BIOS enhancement to block, that shouldn't
affect any OS that obeyed the rules.

My OS obeys the rules - rules that existed in 1990 or earlier -
and thus it isn't me that is at fault.

BFN. Paul.

Grant Taylor

2021-06-18 06:55:02 UTC

The modem is going to look identical to a Windows computer with
Cygwin installed.
Because it is going to be a Windows computer with Cygwin installed.

What does that even mean.

Cygwin supports fork().

How does that help the system(s) that are connected to the modem via
{serial,Ethernet} and {PSTN,DSL,DOCSIS}?

What does the magical modem's ability to fork() actually mean to the
connected computers? How does the modem's ability to fork() help the
connected computers?

I don't care if the modem can magically fry me an egg exactly the way
that I like it, or not, because that doesn't actually have anything to
do with the data I send out the {serial,Ethernet} port to the
{PSTN,DSL,DOCSIS} connection.

What does the modem's ability to fork() do for the connected device?

Telstra even ripped up the copper wire. You have no choice but to
use fiber or 3G.

Sure I do. I always have a choice. There are always options to convert.

You didn't answer what "all I want is my modem back" means either.

I had assumed that a "virtual modem" didn't entail a physical phone
line.

I'll rephrase slightly: how are the computers connected to your modem
going to change what they are doing to be in sync with the modem's change?

What happens to the data that the two computers are exchanging when your
modem does it's fork()?

Does the data stream get interrupted?

Does the modem switch to a different data stream?

How are the computers connected via your modem supposed to deal with
this atypical behavior?

I have no knowledge of certificates,

I strongly suggest that you get at least some knowledge of certificates.
Especially seeing as how certificates are the data that SSL / TLS
encryption is based off of.

I can highly recommend TLS Mastery by Michael W. Lucas. N.B. the "W."
is important.

but I assume Windows has a way of doing that,

Contemporary Windows does. You don't have to go back too far to find
Windows that doesn't have commands to manage certificates.

and the virtual modem will be running under Windows or Linux or BSD
or MacOS.

Didn't you say "Because it is going to be a Windows computer with Cygwin
installed." a moment ago? So ... why the change to now include Linux,
BSD, or macOS?

Yes, I'm throwing that in too.

I'm not sure what's more complicated, a TCP/IP stack or OpenSSL.

One day someone may produce a physical modem that meets the above
criteria and that is the size of a matchbox, but until then, it will
look exactly the size of a PC.

How is it going to look (exactly) the size of a PC if it's /virtual/?

Virtual anything still needs something physical, like RAM.

I would normally say that people know what I mean. But I'm not sure
about you.

I need bluetooth or fiber or something in order to do any sort of
communication.

So you /do/ need a /physical/ network interface for your /virtual/ modem.

Believe it or not, even fiber can respond to "ATDE" with "CONNECT".

I choose "not". Fiber, as the medium for transmitting light, doesn't
respond to commands. Modems or transceivers connected to fiber /may/
respond to commands. Though the commands will probably not be "CONNECT"
and almost certainly not "ATDE".

100 Mbps.

Why 100 Mbps?

Why not 25 Mbps or 250 Mbps?

ATDAnntp://eternal-september.org

Or more importantly, what might it represent?

What significance does what it represents have?

NETWORK=COM1,ATD
meaning a simple fopen of nntp://eternal-september.org

What is the association between nntp://eternal-september.org and NETWORK
(COM1,ATD)?

What would be different to use an encrypted connection? How do you
communicate to the modem that it needs to use TLS?

How do you tell the modem to connect to a different port on the remote end?

Do you have pre-defined devices for each possible remote destination?

Do you have one (or more) device(s) that you open and then pass a
parameter to?

will do an INT 14H to port 0

What ist he association between INT 14H, port 0,
nntp://eternal-september.org and NETWORK (COM1,ATD)?

and send an ATDA followed by the destination I am interested in.

You seem to dislike layers, but layers serve a valuable purpose.

One layer is the physical (or virtual counterpart) communications
between devices. E.g. RS-232, Ethernet, FDDI, etc.

The next layer is signaling protocol that runs on top of and is
independent of the underlying physical connection. E.g. ATD...

The next layer is the application data that the client application
exchanges with the remote server that you're talking to, independent of
how you direct the modem or the physical connection.

Separating the things into distinct layers that have defined
interactions with each other makes each of them a LOT simpler.

I might have another config file ebcdic_hosts.cfg which, if the
filename in fopen is in that list, an ATDE is issued instead.

So ... you'll have an abstraction /layer/ to simplify what other things do.

It should have. That was the defined interface.

I think the operative word in your statement is "was", as in past tense.

All PC compatibles used to have an 8-bit ISA slot in them. Most
businesses on main street used to have a hitching post in front of them.
Times change. Things move on.

If manufacturers insisted that I need to call INT 14H in protected
mode, I can live with that. But that's the interface. That's what
should exist.

"should" being the operative word.

Those are my user requirements.

I suspect that your requirements are going to mean that you have fewer
and fewer systems that meet your requirements.

And I'll zap the firmware to get them.

That assumes that there is a different firmware to put on the system.
There may be, or there may not be.

Or carpet-bomb Taiwan. Whatever is easiest.

I seriously doubt that carpet-bombing Taiwan will get them to put
functionality you want in a system. Especially if the systems you're
using come from somewhere else.

My user requirements are that manufacturers should continue to support
the interface that they provided, unless modern computers don't have
enough CPU power to do so, because we ran out of silicon.

And yet (effectively all) modern computers don't have 8-bit ISA slots.
And it's not because we ran out of connectors.

Well, the manufacturers already said (one way or another) that INT
14H will time out instead of blocking.

Okay....

They defined that interface, so I coded to that interface.

Who is "they"? Do you by chance mean "IBM from the '80s"?

But if I have a BIOS enhancement to block, that shouldn't affect any
OS that obeyed the rules.

And yet a program / OS that relies on something to timeout and detect
that there was no data won't be able to report the lack of data /
timeout to the end user when it's blocked by the BIOS.

My OS obeys the rules - rules that existed in 1990 or earlier -
and thus it isn't me that is at fault.

8-bit ISA, hitching posts, ... times change. Things move on. Old rules
go out and new rules come in.

--
Grant. . . .
unix || die

muta...@gmail.com

2021-06-18 08:21:15 UTC

The modem is going to look identical to a Windows computer with
Cygwin installed.
Because it is going to be a Windows computer with Cygwin installed.

What does that even mean.

Cygwin provides Unix, so you can write crappy Unix
programs on Windows. Windows is crappy too, so
no matter which way you turn, you need to write crap.
Or someone needs to, anyway.

I've found a way of isolating myself from the crap.

Even if I put on another hat and write crappy Unix
code for a while.

Cygwin supports fork().

How does that help the system(s) that are connected to the modem via
{serial,Ethernet} and {PSTN,DSL,DOCSIS}?
What does the magical modem's ability to fork() actually mean to the
connected computers? How does the modem's ability to fork() help the
connected computers?
I don't care if the modem can magically fry me an egg exactly the way
that I like it, or not, because that doesn't actually have anything to
do with the data I send out the {serial,Ethernet} port to the
{PSTN,DSL,DOCSIS} connection.
What does the modem's ability to fork() do for the connected device?

No, this is not my point. Did you know that even GCC,
a friggin compiler, that could have been (and now, is)
written in pure C90, managed to create a dependency
on "fork"? I don't use Unix crap like that myself, but
others plaster their code with it.

So long as this code that deals with TCP/IP, wall to
wall Unix crap, full of forks and opens and god knows
what else, is isolated to the modem (virtual modem
running under Cygwin under Windows), I don't really care.

So long as it just looks like a really fast modem, doing
100 Mbps via INT 14H, I don't care.

Telstra even ripped up the copper wire. You have no choice but to
use fiber or 3G.

Sure I do. I always have a choice. There are always options to convert.
You didn't answer what "all I want is my modem back" means either.

I only recently found out that INT 14H even existed, and
also that MSDOS supports fopen of COM1 (but not "COM1:").

So I have only recently found out "the rules".

Now that I know the rules, I am retrospectively rewriting all
my software. Otherwise it would be unreasonable to
carpet bomb Taiwan.

But if I obey the rules, and the Taiwanese don't, it is justified
to carpet bomb them.

So, I have no problem with manufacturers bumping the speed
of my comms link up to 100 Mbps, but unless there's some
technical barrier, like the speed of light, I expect INT 14H to
give me some of that 100 Mbps. Currently INT 14H on my
Dell gives me crickets.

If INT 14H is restricted to 1 Mbps by the speed of light, no
problem, I'm happy to call INT 14H function 55 instead
which does a block write instead of a character write.

And my OS will gracefully check to see if function 55 exists
or not (not sure how to do that, but other interrupts have
the same issue), and if 55 (which would enable 100 Mbps)
doesn't exist, then it will fall back to function 1, which is
(allegedly) restricted to 1 Mbps.

I had assumed that a "virtual modem" didn't entail a physical phone
line.

I'll rephrase slightly: how are the computers connected to your modem
going to change what they are doing to be in sync with the modem's change?
What happens to the data that the two computers are exchanging when your
modem does it's fork()?
Does the data stream get interrupted?
Does the modem switch to a different data stream?
How are the computers connected via your modem supposed to deal with
this atypical behavior?

Your question is too complicated for me. What I know
is that my modem is already working. You can see it here:

https://sourceforge.net/p/mvs380/mvssrc/ci/master/tree/ozpd/c/modem.c

It's not pretty though.

I have no knowledge of certificates,

I strongly suggest that you get at least some knowledge of certificates.
Especially seeing as how certificates are the data that SSL / TLS
encryption is based off of.
I can highly recommend TLS Mastery by Michael W. Lucas. N.B. the "W."
is important.

I don't want prior art to put me into a rut. When my (working)
modem and my (working) BBS need to be enhanced to
handle "casual snooping", I'll consider what to do about
security.

The first thing I'll ask is why my ISP doesn't encrypt data
if there are so many snoopers between my ISP and the
other guy.

And if my ISP refuses, and I can't get the Australian
government to arrest them for indecent behavior, I'll
instead ask the US to carpet bomb Australia to get
some decent laws enacted.

And if the US is unwilling to bomb Australia, but is
willing to bomb Taiwan, I'll request my firmware to
take care of this instead of my ISP.

I sure as hell can't see (at this stage) why this has
anything to do with me.

but I assume Windows has a way of doing that,

Contemporary Windows does. You don't have to go back too far to find
Windows that doesn't have commands to manage certificates.

And the command can't be added by a 3rd party?

and the virtual modem will be running under Windows or Linux or BSD
or MacOS.

Didn't you say "Because it is going to be a Windows computer with Cygwin
installed." a moment ago? So ... why the change to now include Linux,
BSD, or macOS?

Most of this Unix crap works on all of those environments.
Even the IBM mainframe claims to be POSIX compliant.

PDOS/386 isn't POSIX compliant though. It uses some sort
of MSDOS API called Pos*, as distinct from Bos* which is
the IBM hardware interface standard.

Yes, I'm throwing that in too.

I'm not sure what's more complicated, a TCP/IP stack or OpenSSL.

These GNU asshats can do both.

One day someone may produce a physical modem that meets the above
criteria and that is the size of a matchbox, but until then, it will
look exactly the size of a PC.

How is it going to look (exactly) the size of a PC if it's /virtual/?

I'm lost. The virtual modem needs to run on *something*.
Why not a PC?

Virtual anything still needs something physical, like RAM.

I would normally say that people know what I mean. But I'm not sure
about you.

No, I probably need something like that spelled out.
Don't assume that I have prior knowledge of anything
in particular, or am familiar with any particular
terminology.

I was surprised when I was doing Amiga work that
someone said that all programmers know how to
do 32-bit multiplication using 16-bit instructions.
I'm missing some code I need to support the
68000 and am dependent on a 68020. News to me
that everyone else knows that.

If you describe something to me in terms of C90, I
will likely understand that.

I need bluetooth or fiber or something in order to do any sort of
communication.

So you /do/ need a /physical/ network interface for your /virtual/ modem.

Of course.

Believe it or not, even fiber can respond to "ATDE" with "CONNECT".

Upgrade your virtual modem. :-)

100 Mbps.

Why 100 Mbps?
Why not 25 Mbps or 250 Mbps?

100 Mbps is indicative. The speed is only limited by technology.

ATDAnntp://eternal-september.org

Or more importantly, what might it represent?
What significance does what it represents have?

With the above, a decent operating system will know
what to do. If your operating system doesn't know what
to do, time to upgrade.

NETWORK=COM1,ATD
meaning a simple fopen of nntp://eternal-september.org

What is the association between nntp://eternal-september.org and NETWORK
(COM1,ATD)?

The OS (that reads config.sys) will recognize that for
any networking request ("nntp://" is recognized as a
request for a network connection) should be directed
via COM1 (the OS knows about that too, so does
MSDOS in fact), and that it should use the "ATD"
prefix when dialing out via COM1, as that is what
this particular modem expects.

I'm happy to negotiate these low-level details.

Post by Grant Taylor
What would be different to use an encrypted connection? How do you
communicate to the modem that it needs to use TLS?

At the moment I'm just trying to get a BBS to run.
It hasn't quite passed "proof of concept" stage at
the moment.

I would rather not be burdened by encryption requirements
when I haven't even got sign-off on using XON. Or demonstrated
that zmodem can work across an ASCII to EBCDIC gateway.
Or indeed, what to even code for ZRQINIT in zmodem when
running on an EBCDIC platform that may be communicating
with either another EBCDIC system or an ASCII system via
the gateway.

When I have 1990 modems working to my satisfaction (as I
said, I didn't even know INT 14H existed until recently), I'll
consider what to do about encryption, and hope that I haven't
painted myself into a corner.

But I would hope that any encryption would be handled
by something like the "Squid" that you mentioned. If there
is some technical barrier to putting Squid into my virtual
modem, ok, that's my bad luck.

Post by Grant Taylor
How do you tell the modem to connect to a different port on the remote end?

ATDAeternal-september.org:12345

Post by Grant Taylor
Do you have pre-defined devices for each possible remote destination?

It would be ideal to configure the modem or OS with something
like (in config.sys):

DEFAULT_UUCP=eternal-september.org:550

So that the end user just needs to type:

getnews DEFAULT_UUCP

But I'm willing to negotiate. That's just an example.

Post by Grant Taylor
Do you have one (or more) device(s) that you open and then pass a
parameter to?

If there is some technical reason for the firmware/modem
to need two ports to communicate on, then in config.sys:

NETWORK_SPLIT=(COM1,COM2)

will do an INT 14H to port 0

What ist he association between INT 14H, port 0,
nntp://eternal-september.org and NETWORK (COM1,ATD)?

The OS recognizes that to get any network connection
it needs to talk to a modem designed to accept ATD
commands, and the modem is attached to COM1.

and send an ATDA followed by the destination I am interested in.

You seem to dislike layers, but layers serve a valuable purpose.

I dislike layers if they interfere with anything I am trying
to do. I read about TLS in Wikipedia and they stated outright
that it doesn't fit neatly into any of the OSI layers.

Post by Grant Taylor
One layer is the physical (or virtual counterpart) communications
between devices. E.g. RS-232, Ethernet, FDDI, etc.
The next layer is signaling protocol that runs on top of and is
independent of the underlying physical connection. E.g. ATD...
The next layer is the application data that the client application
exchanges with the remote server that you're talking to, independent of
how you direct the modem or the physical connection.
Separating the things into distinct layers that have defined
interactions with each other makes each of them a LOT simpler.

Ok, I don't have a problem with the above, but I was
doing that anyway, wasn't I?

My main concern is at the application level. I want
fopen() to behave nicely.

I care much less about the OS, and I don't care at all
about the hardware. Bluetooth/greentooth/redtooth,
you can invent as many things as you want, and so
long as the Taiwanese hide it all behind INT 14H,
I don't care. And the C library hides it behind fopen.
And the OS hides it behind either PosOpen or
CreateFile, I don't really care that much, as my apps
do not directly call either, they always go via fopen.

I might have another config file ebcdic_hosts.cfg which, if the
filename in fopen is in that list, an ATDE is issued instead.

So ... you'll have an abstraction /layer/ to simplify what other things do.

I guess so. Isn't that reasonable?

It should have. That was the defined interface.

I think the operative word in your statement is "was", as in past tense.
All PC compatibles used to have an 8-bit ISA slot in them. Most
businesses on main street used to have a hitching post in front of them.
Times change. Things move on.

That's hardware changes. I don't care about that moving on.
I care about the software API to interact with the hardware.

There's no reason to invalidate that, although I will accept
switching to 32-bit registers and then 64-bit registers
instead of 16-bit registers as the register size changes.

That's why INT 14H should be hidden behind a BosSerial*()
function.

If manufacturers insisted that I need to call INT 14H in protected
mode, I can live with that. But that's the interface. That's what
should exist.

"should" being the operative word.

You would be amazed about how well dum-dum bullets
drive a point home. And Gurkhas are available for hire.
And I know where Taiwan is.

Those are my user requirements.

I suspect that your requirements are going to mean that you have fewer
and fewer systems that meet your requirements.

Ok, sure. If I run out of manufacturers (maybe someone
carpet-bombed them or something), I'll resort to running
Bochs on an IBM mainframe or something.

My BBS might start malfunctioning if I do that though,
as it is designed to respond to keystrokes, not lines.

It is ironic that I haven't even secured characters, while
other people insist that graphics are mandatory.

ie I'm not even at the point where I can safely write a
character-mode program.

And I'll zap the firmware to get them.

That assumes that there is a different firmware to put on the system.
There may be, or there may not be.

Isn't that what GNU asshats are for?

Or carpet-bomb Taiwan. Whatever is easiest.

I seriously doubt that carpet-bombing Taiwan will get them to put
functionality you want in a system. Especially if the systems you're
using come from somewhere else.

It's the thought that counts.

My user requirements are that manufacturers should continue to support
the interface that they provided, unless modern computers don't have
enough CPU power to do so, because we ran out of silicon.

And yet (effectively all) modern computers don't have 8-bit ISA slots.
And it's not because we ran out of connectors.

I don't mind that.

Well, the manufacturers already said (one way or another) that INT
14H will time out instead of blocking.

Okay....

They defined that interface, so I coded to that interface.

Who is "they"? Do you by chance mean "IBM from the '80s"?

I guess so. I just look up RBIL. I assume he got it from
somewhere definitive.

But if I have a BIOS enhancement to block, that shouldn't affect any
OS that obeyed the rules.

And yet a program / OS that relies on something to timeout and detect
that there was no data won't be able to report the lack of data /
timeout to the end user when it's blocked by the BIOS.

Sure. So the end user shouldn't set "blocked reads" if
he is running such an application+OS. And the
manufacturer should probably have it time out by
default or risk being carpet-bombed.

My OS obeys the rules - rules that existed in 1990 or earlier -
and thus it isn't me that is at fault.

8-bit ISA, hitching posts, ... times change. Things move on. Old rules
go out and new rules come in.

S/360 applications that obeyed the rules continue
running in 2021. That's what professionals (IBM) do.

BFN. Paul.

muta...@gmail.com

2021-06-19 03:07:53 UTC

Post by ***@gmail.com
That's hardware changes. I don't care about that moving on.
I care about the software API to interact with the hardware.
There's no reason to invalidate that, although I will accept
switching to 32-bit registers and then 64-bit registers
instead of 16-bit registers as the register size changes.

If manufacturers insisted that I need to call INT 14H in protected
mode, I can live with that. But that's the interface. That's what
should exist.

You know - I would have liked the manufacturers to have
produced a 32-bit interface right from the start. So that I
am not saddled with 16-bit code for eternity.

But that's the interface they provided. They said that if I
wanted to access the hard disk/serial port, and even to
boot, that I must be in 16-bit real mode. No BIOS setting
for the MBR to be executed in flat 0-based PM32.

They are the ones who created very annoying rules. I
wrote (albeit slowly) the code to conform to their rules.
Now the onus is on them to live by their own rules.

Some people on Fidonet used to complain that the rules
were the comms software needed to support Xmodem.
Why not zmodem? If Fidonet wants to mandate zmodem,
I don't have a problem with that if we can be sure that
there is no-one who wishes to run on a platform that
doesn't support zmodem. I wrote a public domain
version of zmodem, but until it has been built for a C64
and we still have C64 users connecting to Fidonet, xmodem
can't be invalidated.

Once public domain software has been put in the hands
of the C64 users and there is no discernable reason as
to why they can't use it, that's when I don't mind Fidonet
changing the rules. Someone is deliberately using xmodem
to disrupt the rest of the organization.

It is only with Win 10 that ANSI is supported. I intend to make
use of that feature (it's already in place), but I know that it
won't run on Windows 95. The onus is on me to solve that
problem. Those old computers running Win 95 can't be
willed out of existence. I might ask them to boot their
computer from floppy disk to run a future PDOS/386 that
actually supports ANSI (it doesn't currently), so that they
can run the ANSI version of micro-emacs (pretty crappy
at the moment, but it sort of works). Otherwise I still have
a Windows-specific version of micro-emacs that runs on
Win95.

BFN. Paul.

Rod Pemberton

2021-06-22 08:52:14 UTC

On Thu, 17 Jun 2021 22:29:54 -0600

[...]

I would rather you contribute to [...]

This strikes me as rather wrong.

I mean, I would rather lots of
other people do lots of other
things, which would benefit me.
Of course, I'm not entitled.

The trouble is that the system I am most interested in is PDOS/386
which only supports C90. Well, sort of.

Either it does, or it does not.

If it only supports a subset of C90,
then it both does and does not.

It "does" support C90 /only/.
It "doesn't" support C90 /fully/.

Adverbs. Missing.

How is an operating system the limiting factor of what level of C is
supported?

I'd say the OS implementer is "the limiting factor of
what level of C is supported" in an OS.

I.e., the designer may choose to limit what portions
of C and the C library in used to implement the OS.

E.g., I limited my OS project to the C language proper,
and a few string and memory functions, as they were
OS independent for the C compilers I was using. I've
limited many utilities that I wish to bootstrap to just
the C language proper, stdio.h, stdlib.h, and string.h.

Shouldn't that be the compiler's job?

So, it's the compiler's job to determine what level
of C is used in an OS? Just how much "intelligence"
do you expect a compiler to be imbued with? How do
you expect humans to enhance the C compiler with that
much intelligence without using Artificial Intelligence? ...
The C compiler would need to be nearly sentient.

I want to flesh out what is possible with C90.

You're free to impose your own artificial restrictions.

Does he really need you to tell him that?

He seems to fully understand he has gone
off-into-the-weeds, unlike other people
on Usenet. Perhaps, it's brainstorming,
or urgency, and not insanity.

What existing C90 browser do you suggest I use instead of creating
my own? Preferably one that is public domain.

I have no idea what falls within your artificial self imposed
restriction.

Nothing.

C90. Maybe.
Public domain? Nothing.

I'm quite certain that there's source code for Netscape from the '90s
available on various Linux archives. I'm confident that there is
source code for other browsers.

Am I correct in saying that your intent seems
to be to redirect Paul from his OS project to
some other huge time-wasting project? ...

Moving OpenSSL code to the modem means that my OS is uncomplicated.

You're committing multiple layering violations for a very
questionable idea.

What is a "layering violation"? Bad hair cut?

Over any physical connection there can only be
a single stream of data, regardless of serial,
parallel, or multiplexed, etc. If you wish to
subdivide that data and call various pieces of
it different things, e.g., header, signaling,
data, checksum, it doesn't change the fact that
there is only one stream of data over the
physical connection. In other words, the data
is all merged together in some format. You
can call it layers, if you wish, or because
some protocols specifies it that way ...

All I want is my modem back. I never agreed to give it up. Or the
attached BBS software.

What do you mean "want is my modem back"? I don't recall anyone
taking your modem from you.

Instead of chastising him for his preference of
the ancient and IBM, you could've had him search
for a "USB modem". Dial-up. 56K. Fax modem.
They're still being manufactured and sold, e.g.,
e-mail for laptops on business trips. He could
buy one tomorrow. Unfortunately, an "Ethernet
modem" is a cable modem, and isn't dial-up, but
there are Ethernet-to-RS232C adapters which he
could use with an external dial-up modem.

Similarly, your idea of moving OpenSSL into the modem, how are you
going to communicate all of the parameters that are used to establish
SSL / TLS connections to the modem?

That's easy. Webpages.
Just like an Ethernet cable modem.

How are you going to provide the
trusted root certificate store?

Via any file transfer app or protocol? ...

Modem's don't have any storage to
speak of (NVRAM is miniscule) and /etc/ssl on my modern system is
about half a MB. How do you manage that certificate store on the
modem?

Since it's apparently only in his head
at this point, it will ...

Or, you can think of a cable modem, which
supports many protocols, is frequently
implemented as an embedded Linux computer,
and has enough storage to update it's
software. Except, he wants dial-up ...

How does the OpenSSL on the modem initiate a TCP/IP connection when
modem's don't speak TCP/IP. Or are you throwing that in too?

SLIP. PPP.

A dial-up PSTN based modem can't really go any faster than about ~30
kbps (line rate) because of problems encoding data. Problems as in
you need to sample the line at least twice as fast as the signal you
want to send through it to have any hope of getting things to work.
The 33.6 ~ 56 kbps (serial rate) was data compression applied to the
serial stream to shrink it down to the ~30 kbps (line rate). So ...
how are you going to make a dial up modem faster than physics can
allow?

They did improve the transmission rate
somewhat, but I don't recall as to what,
as dial-up modems were basically obsolete
by then.

Even if you're talking Ethernet / {DSL,DOCSIS}, you are still limited
to what the {DSL,DOCSIS} network can carry.
So ... what is going to be faster about your modem?

Static ram? ...

Asynchronous clocking? ...

Memory? ...

Embedded microprocessor? I.e., not a 1MHz 8-bit
6502 or Z80 etc. E.g., a modern GHz class such
as an ARM or x86.

I'd suspect the last two, at least.

But all this should be transparent. At least if I follow the rules,
1. Apps should fopen COM1 or preferably a user-defined string to
get access to the modem,...

What might the user defined string be? Or more importantly, what
might it represent? What significance does what it represents have?

Magic number. Always best if hard-coded ...
The deeper it's buried inside the code base,
the better. The point is to make sure
that absolutely no one can ever find it.
If the #1 rule of real estate is "Location,
Location, Location," then the #1 rule of
programming is "Obfuscation, Obfuscation,
Obfuscation."

(I'm marking that as sarcasm and humor,
as someone, at some point, is unlikely
to grasp this fact ... And, I'll get
ripped for being dead serious and wrong.)

...so let the OS take care of that.

Wait a minute. You have been saying that you wanted the modem to
take care of this. Now you are wanting the OS to take care of this.
Which is it? If it's now the OS and no longer the modem, why the
change?

...

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.

I don't care how the OS accesses the serial port.

Are you coding an OS? If not, I fully
understand your point, but now I'm
truly wondering why you're actually here.
(Actually, not just you, but a few new
guys who're posting here now.)

I doubt that relying on INT 14H will actually future-proof the OS.
If anything, I expect that it will future-harm the OS. -- See the
recent discussions about BIOS support. -- I believe relying on INT
14H will effectively limit your solution to legacy systems that still
support BIOS.

Yes.

But, he's coding an x86 OS for an IBM
mainframe, executing via an emulator or
some such bizarre setup ...

So, what really do you expect of him?

--
What is hidden in the ground, when found, is hidden there again?

muta...@gmail.com

2021-06-22 10:16:57 UTC

Post by Rod Pemberton
But, he's coding an x86 OS for an IBM
mainframe, executing via an emulator or
some such bizarre setup

PDOS/386 is an 80386 OS for an 80386 computer
and is available to burn onto a USB stick near you.

http://pdos.org

There isn't one skerrick of mainframe code in it,
although if you sniff around the source code you
will see a separate "s370" directory, and if you
sniff around PDPCLIB you will see some #ifdefs
for mainframe targets, but there's no reason to
take an interest in that.

You do need a 16-bit BIOS (via CSM is fine) to boot
it though, as has been the case since 1986 until
recently, and ignoring Macbook which is doing
something abnormal that I haven't figured out yet.

BFN. Paul.

wolfgang kern

2021-06-22 10:25:26 UTC

On 22.06.2021 10:52, Rod Pemberton asked Grant Taylor:

[about giving advice to Bill Cunningham, oops err Paul Edwards]
[snipped the obvious]

Post by Rod Pemberton
So, what really do you expect of him?

I'd say let the guys talk weird until exhausted :)
at least this keeps Usenet alive. We could invite
Flying Bucket to join this interesting insanity.
__
wolfgang

muta...@gmail.com

2021-06-22 11:17:44 UTC

Post by wolfgang kern
Bill Cunningham
Flying Bucket

I did a search for both of these presumed cultural
references, but didn't find anything seemingly
relevant.

I'm pretty old, so it's difficult for things to be before
my time. But I've been outside of most modern
culture. What's happened since I went into
hibernation?

BFN. Paul.

Joe Monk

2021-06-22 15:01:54 UTC

Post by ***@gmail.com
I'm pretty old, so it's difficult for things to be before
my time. But I've been outside of most modern
culture. What's happened since I went into
hibernation?

LOL. Im a boomer, so I got you beat by just a few years :)

Joe

Rod Pemberton

2021-06-23 11:17:56 UTC

On Tue, 22 Jun 2021 04:17:44 -0700 (PDT)

Post by ***@gmail.com

Post by wolfgang kern
Bill Cunningham
Flying Bucket

I did a search for both of these presumed cultural
references, but didn't find anything seemingly
relevant.

Who is Bill Cunningham? ... IDK.

Apparently, Bill Cunningham posted here and
on alt.lang.asm for a few years, but rather
infrequently. Since I don't really remember
him or his posts, I'm not really sure what
wolfgang was referring to. However, his 2014
posts sound /exactly/ like you ... Alias?

wolfgang's nickname for skybuck2000 is "Flying Bucket".

Skybuck has posted weird paranoia infused programming
related TL;DR rants for decades. He was very active
some years ago. He's only been posting to alt.lang.asm
for the past few years and very infrequently now.

--
What is hidden in the ground, when found, is hidden there again?

muta...@gmail.com

2021-06-23 10:30:03 UTC

Post by Rod Pemberton
Apparently, Bill Cunningham posted here and
on alt.lang.asm for a few years, but rather
infrequently. Since I don't really remember
him or his posts, I'm not really sure what
wolfgang was referring to. However, his 2014
posts sound /exactly/ like you ... Alias?

Exactly like mine? I can't even categorize my
own posts so don't even know what that means.

2014 is within the time period I was posting on
alt.os.development, although maybe it was during
a period where I was doing battle with the
mainframe, so had a different group for that.

Regardless, no, I don't use an alias. I use a
nickname of "kerravon" for my userid whenever
I have to give one, if you count that.

BFN. Paul.

Kerr-Mudd, John

2021-06-23 19:03:45 UTC

On Wed, 23 Jun 2021 03:30:03 -0700 (PDT)

Post by ***@gmail.com

Exactly like mine? I can't even categorize my
own posts so don't even know what that means.
2014 is within the time period I was posting on
alt.os.development, although maybe it was during
a period where I was doing battle with the
mainframe, so had a different group for that.
Regardless, no, I don't use an alias. I use a
nickname of "kerravon" for my userid whenever
I have to give one, if you count that.
BFN. Paul.

Bill is /was a very successful troll of the old school.

--
Bah, and indeed Humbug.

wolfgang kern

2021-06-24 05:13:16 UTC

Post by Kerr-Mudd, John

Post by ***@gmail.com

Exactly like mine? I can't even categorize my
own posts so don't even know what that means.
2014 is within the time period I was posting on
alt.os.development, although maybe it was during
a period where I was doing battle with the
mainframe, so had a different group for that.
Regardless, no, I don't use an alias. I use a
nickname of "kerravon" for my userid whenever
I have to give one, if you count that.

Bill is /was a very successful troll of the old school.

Yeah, this poor lad is locked in his own jail where the
walls are made from ignorance and stubborn believe.
He could not accept that 0x00 isn't a NOP on x86 and he
tried to modify his MBR by disassemble msg-text. :)

But he may have learned a lot meanwhile, now at least
that you always get silly answers for stupid questions.
__
wolfgang

Rod Pemberton

2021-06-23 11:15:09 UTC

On Tue, 22 Jun 2021 12:25:26 +0200

We could invite Flying Bucket

NO! No, no, no no no, no and HELL no ...

Flaming Fart Cloud almost doesn't post anymore.

(There are at least two answers to my riddle. No takers so far ...)

--
What is hidden in the ground, when found, is hidden there again?

Rod Pemberton

2021-06-18 05:00:55 UTC

On Thu, 17 Jun 2021 12:53:19 -0700 (PDT)

Post by ***@gmail.com
There are some servers that are using old software
with no easy way to upgrade to a later version of TLS.
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.
When I was using a BBS and occasionally dialing the
US (from Australia), it was all unencrypted traffic, so
some random telephone company staff had access
to my passwords. I don't really care. I was never
running Fort Knox.
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.
The browser people seem to be in a conspiracy to
prevent people from accessing a TLS 1.0 server,
even internally within a company.

Early TLS (1.0, 1.1) is obsolete and has mostly been
eliminated in favor of later versions (1.2, 1.3).

It's not "the browser people" but the IETF who
obsoleted SSL and early versions of TLS:
https://www.ietf.org/

I.e., no one will be able to connect to your BBS
via TLS 1.0, unless they still have a copy of an
obsoleted browser.

The IETF, along with ARIN, ICANN, IRR, RIPE, and W3C
etc manage various aspects of the Internet.

As for other obsolete protocols you should avoid:

SSL is obsolete and has been eliminated.
FTP is obsolete and has mostly been eliminated.
HTTP is obsolete and is quickly being eliminated.

TELNET is obsolete and has been eliminated for logins,
but can still be used for connections to NNTP, SMTP, etc.

HTTPS is in use.
NNTP is in use.
IRC is in use.
SMTP is in use.
DNS is in use.
SSH is in use.
...

The one that shocked me recently was FTP. I didn't
expect FTP to ever go away, but it's mostly gone
now, replaced by HTTPS. It's a bit like payphones.
They disappeared rapidly here about a decade ago,
after widespread adoption of smartphones. Airports
are one of the last places you'll still find them.
There are no payphones at gas stations, fast food
restaurants, grocery stores, hardware stores, etc,
but you may still find them at rural gas stations.

--
What is hidden in the ground, when found, is hidden there again?

muta...@gmail.com

2021-06-19 18:02:45 UTC

Post by Rod Pemberton
HTTP is obsolete and is quickly being eliminated.

How can http be eliminated when encryption is illegal
in some countries?

If I make port 80 open on my system (kerravon.mooo.com)
is someone (my Australian ISP) going to block it?

Thanks. Paul.

Elijah Stone

2021-06-19 07:21:15 UTC

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.
The browser people seem to be in a conspiracy to prevent people from
accessing a TLS 1.0 server, even internally within a company.

There are very sound reasons to disallow the use of TLS 1.0 entirely.
Namely: downgrade attacks. There is no conspiracy.

(That being said, I'm not sure what browser vendors were smoking when
they decided that a self-signed certificate is cause for a
!sensationalistic! warning, but an unencrypted connection is not.)

Sounds to me like there's a market for a rival browser that enables the
use of TLS 1.0, perhaps with a warning.

Not really. You can (relatively) trivially compile old versions of
chrome/firefox.

I assume there is no public domain code available to do [TLS]

https://github.com/eduardsui/tlse

muta...@gmail.com

2021-06-19 17:49:40 UTC

The browser people seem to be in a conspiracy to prevent people from
accessing a TLS 1.0 server, even internally within a company.

There are very sound reasons to disallow the use of TLS 1.0 entirely.
Namely: downgrade attacks. There is no conspiracy.

What downgrade attack are you talking about when
a browser is used internally within a company?

Sounds to me like there's a market for a rival browser that enables the
use of TLS 1.0, perhaps with a warning.

Not really. You can (relatively) trivially compile old versions of
chrome/firefox.

By "chrome" did you mean "chromium"? I don't think the
former is open source.

I assume there is no public domain code available to do [TLS]

https://github.com/eduardsui/tlse

Thanks. The code is BSD and it uses a library which doesn't
have a copyright notice, but doesn't have a "public domain"
dedication either. So it's probably classified as implicitly
copyrighted freeware.

BFN. Paul.

Elijah Stone

2021-06-20 06:17:46 UTC

Post by Elijah Stone
There are very sound reasons to disallow the use of TLS 1.0 entirely.
Namely: downgrade attacks. There is no conspiracy.

What downgrade attack are you talking about when a browser is used
internally within a company?

A browser has no way of distinguishing a corporate-internal website and a
public one.

Post by Elijah Stone
https://github.com/eduardsui/tlse

The code is BSD and it uses a library which doesn't have a copyright
notice
Public domain, BSD, MIT. Choose one.

-E

muta...@gmail.com

2021-06-20 06:34:05 UTC

Post by Elijah Stone
There are very sound reasons to disallow the use of TLS 1.0 entirely.
Namely: downgrade attacks. There is no conspiracy.

What downgrade attack are you talking about when a browser is used
internally within a company?

A browser has no way of distinguishing a corporate-internal website and a
public one.

Can't that be done at the corporation level - convert external
traffic into TLS 1.2 using Squid?

If it can be done, then shouldn't the browser give people the
option to turn on TLS 1.0 because the company is protecting
them?

Thanks. Paul.

Grant Taylor

2021-06-21 03:11:24 UTC