Hacker News new | comments | show | ask | jobs | submit login
Securing Telnet with SSL (ibm.com)
43 points by AJAlabs 23 days ago | hide | past | web | 20 comments | favorite



I'm guessing that something about ssh makes it difficult to implement the block oriented (vs stream) comms that protocols like 5250 and 3270 need. Unlike the unix world, they can interact with the terminal without sending things to the host, and there's support for something sort of like html forms, tab traversal, etc. They fill out fields and press a send key. You can't, for example, use a normal telnet client. There's tn3270, tn5250, etc, that layer the extra stuff needed.

You can find "sortof ssh" solutions for AS/400's and z/OS, but they create a tunnel and it's still telnet underneath. Or solutions that are ssh, but are interacting with a linux partition, or posix subsystem, and can't do the 3270/5250 stuff.


This is a throwaway. Five years ago I worked for a company that was still using telnet for everything.

Despite assurances of using encryption to clients, we were taking no security measures. Connections to servers were possible with UUCP and Telnet over the internet and modem.

We "upgraded" to SCO OpenServer 6 because we were already grandfathered in to it and three servers had died.

We also had a zero password policy. If you could find the port or the phone number and you could guess a username, such as oh I don't know: "root", then you could get in.

And people were. We were regularly getting modem calls after hours. We had medical records, private financial data, social insurance numbers, ...

It was such a painful work environment. I switched us over by claiming that OpenServer 6 did not have a telnet server and that we were going to have to switch to SSH. I also lied and said that passwordless SSH sessions weren't a configurable option.

My point? This sort of half-assed mitigation of people stuck in their ways doesn't accomplish much. Best to just lie to them, if they were educated they would have already made the change of their own volition.


Ok so a few people posted about why not ssh? I think I'll try to provide more context to the system they are describing.

You are a brokerage and your Setup with IBM is a mature system that would cost you lots of capital to overhaul to SSH. Your already have a plan to do this and it will take 1 or 2 years to roll out and justify the cost to the board of directors. This answers the question : What do I do now to secure this system.


VPN or SSH (reverse) tunneling. This looks a lot like IBM making things so complex that you need to hire their consultants.


That's what they are doing.

They are just doing it within the 5250 emulator instead of setting up a separate tunnel with a VPN or SSH port forwarding scenario.


I think you'll find that this is exactly what's happening here-its telnet talking through an SSL tunnel. Nothing crazy


Call me edgy, but what about ssh, Bob?


A: Because Bob lives in alternate universe where you still define technology options around IBM offerings like it was 1987. His new financial startup is like an early cloud computing customer -- entering into a time sharing agreement with his local bank to utilize their excess MIPS via ISDN. :)

If you're using a stack dependent on 3270/5250 connectivity, you're better off using stuff like this. IBM supports it end to end, and it will support all of the functions in the terminal without code changes or other workarounds. Nowadays increasingly fewer people actually know what they are talking about with these technologies, and you're better off touching as few things as possible!


Mainframe and midrange people probably find the relatively recent NoSQL movement similarly amusing. Fast KV store seems important to you, eh? Just figuring that out? What if it came with OS level awareness?


"Bob" is using some kind of "old iron" possibly emulated on mainframe and communicates to it with a retro terminal client (5250 ?).

So... do brokerages use telnet in the wild?


Well, I know of at least one iSeries (AS400) software vendor who does use it in the wild.


there are many trading floors which are still run by IBM mainframes which do still use telnet


"Modern" (ha!) Bulletin Board Systems that support SSH simply talk Telnet over a SSH tunnel.

Sometimes you don't want to change... Much. :)


This article prompted me read more about the IBM i OS [1], and it sounds actually quite cool. From the self-healing and objects instead of files, to the packaging of an IR to be re-compiled on the fly to new platforms, I'm curious to know why it and its concepts aren't more mainstream? Is it actually the bees knees but just costs a lot?

[1] https://en.m.wikipedia.org/wiki/IBM_i


You would likely find similar things regarding other midrange and mainframe systems. HP3000/MPE, DEC VAX/VMS, IBM z/OS.

Vax, for example, had functional clusters, versioned filesystems, and other goodies, many years ago.

Just the nature of a proprietary system...controlling everything means some functionality is easier to implement, more elegant, etc. Apple still takes advantage of this.

The hardware and OS licensing costs are high, as you suspect.


"VAX had versioned filesystems"

I think that's a stretch. It had file-name;rev where each time you wrote the file it bumped $rev. As an SCM guy, that's not versioning, that's automatic backups. And you have to run purge all the time to free up disk space.

I don't mean to be pedantic but this is the second time I've seen this claim in the last few days.


That's what they are called though..."versioning filesystems". I didn't compare it to SCM. It is probably more comparable to snapshots. The number of revisions held is configurable.


Yeah, wasn't trying to nitpick, just pointing out that as a file system guy (I did a pile of work on UFS at Sun) and an SCM guy, I don't think that we want people to think of what VMS had as a versioning file system.

To me, a versioning file system has a dag, the OS creates a node everytime you close it with modifications; if two people close at the same time then just like BK or Git you fork the graph, which means the next time someone opens it it has to be merged.

As I said elsewhere, it would be super cool to have such a thing for /etc, if you wack a config, debian wacks it, you upgrade, you then get all the features that an SCM system give you for merging. I dunno what Git gives you but BitKeeper does a kickass job of automerging and has a complicated but pleasant graphical file merge.


> As I said elsewhere, it would be super cool to have such a thing for /etc, if you wack a config, debian wacks it, you upgrade, you then get all the features that an SCM system give you for merging. I dunno what Git gives you but BitKeeper does a kickass job of automerging and has a complicated but pleasant graphical file merge.

Etckeeper [1] does this. There's also etcd, but that seems to be more akin to Puppet and Chef. Disclaimer: I've never used any of the mentioned software.

[1] https://etckeeper.branchable.com/


I am wondering if they could implement SSH service and use a SSH tunnel to telnet avoiding recode of the telnet end points.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: