AmiSSL / OpenSSL updates to support TLSv1.1/1.2?

[olsen]

So I'm not sure how much any of the Amiga community pays attention to all the nasty vulnerabilities that have been hitting the world lately, but apparently SSLv3 is now pretty much considered crap, as well as TLSv1.0.  

I was wondering if there are any plans to update either AmiSSL or the port of OpenSSL to a newer version that doesn't make SSL encrypted sites completely useless?

http://sourceforge.net/projects/amissl/

http://amiga.sourceforge.net/OpenSSL/

Which project is still the most developed?  Kind of silly to have two 'standards' for it.

slaapliedje

As far as I know AmiSSL is being worked upon, but technical difficulties with regard to the 68k build are currently making progress really, really hard.

[olsen]

Probably would be beneficial to look at something other than openssl as a base for a library on the amiga such as polarssl (https://polarssl.org/). Much smaller - I use polarssl on the original xbox for xbmc4xbox for libcurl and librtmp.

https://polarssl.org/openssl-alternative

Contemporary Amiga software which uses the SSL/TLS functionality requires API compatibility with amissl.library, which makes a port of PolarSSL a difficult option at best.

Prior to amissl.library OpenSSL-based SSL/TLS solutions did exist, for example in Miami & Miami Deluxe, so it's not mandatory to have a single SSL library API.

However, much of the existing Amiga software that uses SSL/TLS relies upon a specific library and its API and cannot be easily changed, if it can be changed

[olsen]

Amiga systems are not suited for Internet anyways. With no development or even interest whatsoever in modernising the IP stacks, and with a software suite that is stuck in mid 90ies and close to impossible to update due to status of source code and licenses - why bother.

I'm having a really, really hard time reading this as a non-ironic contribution to this thread.

We're in splendid company concerning the restrictions you mentioned. Much of the Internet as it exists today uses TCP/IP stack software which has not changed that much since the 1990'ies. The fundamentals are resilient and still work, in spite of the fact how old the code actually is (portions of the 4.4BSD TCP/IP stack go back to the original BBN implementation).

That SSL/TLS support for AmigaOS is not as nice as it should or could be is a sad fact, but it's arguably a fixable problem which requires a lot of work.

[olsen]

What splendid company? Much? My profession is system and network administrator for an NREN, I have a pretty good idea about which operating systems that have active developed and maintained IP stacks and which do not. The Amiga stacks are so way behind that it is not even funny.

The Amiga fares pretty well like all other contemporary consumer grade equipment, including game consoles and other internet-enabled appliances. Which boils down to the fact that the TCP/IP stack is old, aging, and the SSL/TLS functionality may not be up to current standards with regard to the ciphers supported and enabled by default.

That isn't to say that the Amiga stinks, it's just that everybody else doesn't have higher standards either. As for security, you don't have much on the Amiga, and the same tends to be true for internet-enabled appliances. We're in splendid company indeed.

Some of the side-effects of having networking software installed which is behind the curve can be mitigated by not having these devices talk directly to the internet, but have them firmly behind a firewall/router, and no means for the outside world to bypass the filtering.

Such measures only go so far, though. The fact remains that the Amiga is not a secure system, and cannot be reasonably expected to provide such security in the future.

You can't hold this platform to the same standards as you would hold modern, professional grade equipment. The Amiga plays in the "consumer electronics" field, and does not, cannot play with the big boys.

The fundamental TCP/IP stack software and even the SSL/TLS software still does work, though, it's just more brittle than some people, myself included, are comfortable with. But then I'm uncomfortable enabling my AV receiver's "phone home" feature, or my BluRay player's similar functionality. You must assume that the device's maker has no clue about network connected device security and will make you regret enabling it, unless the device maker produces conclusive evidence to the contrary.

[olsen]

Aren't most IP stacks based largely on the BSD reference?  Even if written from scratch, I don't think IPv4 has changed much at all in recent years.

In any case, does RoadShow not count as recent development of IP stack for the Amiga??

Not really. I started writing Roadshow after the OS 3.9 release showed that there was a need for another TCP/IP stack. That was almost 15 years ago. Also, the TCP/IP stack source code which Roadshow is based upon was originally released in 1994 as part of 4.4BSD-Lite2, which makes it barely 5-6 years younger than AmiTCP (which uses code from a 1988/1989 BSD kernel, ported to the MACH kernel).

[olsen]

I think the message kolla is trying to get through that they lack IPv6 support. And even they did our web applications need to be updated to support IPv6.

Havent still noticed any problems, yet.

I believe that IPv6 support will remain a non-issue for at least a decade. There are just too many IPv4-only devices around which cannot be upgraded. And you don't have to upgrade them: your gateway router will at some point talk IPv6 to your ISP, but alsoact as an IPv4 tunnel/gateway, so that you may keep on using your network-enabled devices.

You should start pondering a change to IPv6 as soon as Apple releases products which not only support IPv6 out of the box, but also choose IPv6 as the default configuration (as opposed to IPv4). I don't expect this to happen in this decade.

[olsen]

Ha, yeah isn't that the painful truth.  

I noticed they are finally doing something with m68k MUI (updated to 3.9 beta).

I also found this;

http://sourceforge.net/p/amissl/code/HEAD/tree/

Looks like they're updating it to OpenSSL 1.0.1i

They are *trying* to update it, and they met with substantial difficulties with regard to how OpenSSL can be ported to the Amiga.

[olsen]

You have any documentation about Apple not using IPv6 as default? I have had my Apple products on IPv6 only networks, and it worked fine, by default, out of the
box.

Good point. And bonus points for actually trying this ;-)

The last time I was this adventurous I found that my Mac Mini basically did work with my dual-stack ADSL gateway router, but there was no actual benefit (my ISP only supports IPv4, and IPv6 traffic was tunneled by my gateway router). In the end I stuck to IPv4 and disabled IPv6 negotiation.

What I was getting at, however, is in Apple making IPv6 the default option and disabling IPv4 configuration by default, leaving it to the customer's discretion to enable it if needed. As far as I know this hasn't happened yet. In your typical home network setup you will still find devices which only support a single IPv4 stack, and which are not easily replaced.

Your dreamy ISP box is not happening anytime soon, the marked for such a device is not big enough and these days transition protocols are all about making the IPv4 world available for IPv6 only devices - _not_ the other way around, like you suggest!

Hm... that sounds like network engineering talk rather than sales talk to me. How are you going to sell this to the customer? He'll have to replace gear that isn't broken, maybe only 3-4 years old, doesn't support IPv6, or shows IPv6 interoperability issues. What now?

This isn't going to be a niche problem. The possible solutions for keeping IPv4-only devices connected to the Internet which I read about didn't exactly warm my heart. If it's web-only traffic, you could solve the problem with a traditional HTTP proxy, maybe even a socks-like service for the rest. But that proxy would have to sit in the network of your ISP, which would raise privacy issues, to say the least (correlating DNS lookups with TCP connections isn't so simple today, but with such a proxy solution your ISP will know both). Would you trust your ISP to proxy your encrypted web/mail/whatever traffic?

How do you plan to map the vast number of IPv6 addresses out in the world to the small number of IPv4 addresses behind your magic router?

Through some unholy combination of NAT and DNS. The number of connection end point tuples your basic IPv4 firewall needs to be able to wrestle with is comparatively small over time, if you're connecting a home network to the Internet through a gateway router. Caching/mapping AAA record information from DNS queries is ugly, but could be done assuming that the number of records that would have to be dealt with is small over time, too. Tweaking DNS lookups in this manner could just about work in home network, but it would create problems if the mapping between IP address and DNS record were use for purposes of verifying correctness. You could forge DNS records and the DNS proxy/mapping solution would make it impossible to detect the forgery.

Things will undoubtedly get really ugly the more important IPv6 deployment becomes, rendering a IPv4/IPv6 NAT/DNS mapping scheme unwieldy. But I bet you five Eurocents that this is what we'll get at some point when the transition from IPv4 to IPv6 happens.

And no, it is not just IPv6 that lacking, there is also basic stuff like working path MTU discovery, anything doing with multicast (MiamiDx has a little), a whole range of DNS related issues, ancient DHCP implementations...

Yes, it would be helpful to have path MTU discovery. For me (Roadshow lacks MTU discovery) this is a customer support problem. Luckily, you can get get by with a 1500 octet Ethernet MTU today. This used to be very different a decade ago.

[olsen]

My major point is this - the day your ISP says "%&$#?@!%&$#?@!%&$#?@!%&$#?@!it, enough of this IPv4 legacy crap", you are screwed, ISPs can easily flip over night and vast majority of users will not notice. You see, this is how the teansition is meant to work! And no, they will not develop a special magic router just for us retro fans.

Do you actually believe that this is a sensible strategy? No doubt it's possible to make this change, and at the ISP's side of the business it matters little what flavour the IP packets have, but does it benefit the customer in any way whatsoever?

The ongoing transition from the plain old telephone system and its more modern digital telephony incarnation to VoIP is not exactly a painless process either, and in the end the only thing the customer may have to do is to replace a comparatively cheap handset.

Home users and corporations still use ISDN gear, almost ten years after it became clear that IP had won the battle. Unlike for hand-held mobile devices there is no steady product development cycle which drives sales and replacement of old gear in this market. Dual stacked IP network devices have only started to become cheap and robust in the last few years.

Unless your ISP can afford not to care about its customers (not unheard of; prevalent in countries in which there is no or very little market competition), a forced switch from IPv4 to IPv6 would be economically unsound.

[olsen]

Olsen, clearly you do not understand that the transition is already happening, and it is IPv4 that is left behind.

I understand that it is underway, my point was just that with the type of devices that are still IPv4 only, cannot be easily upgraded if at all, and are installed in sufficient numbers, you can't just force a switch to IPv6 without taking care of your customers.

For example, one German ISP ran out of IPv4 address space and had to use IPv6 for new customers. Those customers who owned game consoles (XBOX360, PS3, etc.) found that they could no longer go online, because these devices supported only IPv4 operations and the ISP's NAT was not up to the task. As far as I know even the current console generation (XBOX One, PS4, WII-U) is not entirely IPv6 compliant yet, part of which may be due to how the game server infrastructure operates, and what happens if players which use IPv4 and IPv6 need to talk to one another.

A game console is the type of device which I have in mind when it comes to make a transition from IPv4 to IPv6 easier because the manufacturer may not be particularly helpful, the device is not cheap and is not easily replaceable during the next product cycle (6-7 years for a game console?).

I do realize that ISPs and carriers are itching to get rid of IPv4, especially if their customer base is very large. A corporation such as Comcast probably has its subscribers NAT'ed several layers deep to avoid running out of public IPv4 address space. Never mind the cost, it makes the network operation unnecessarily, if not nightmarishly complex.

Here is an example of what is going on...

https://sites.google.com/site/tmoipv6/lg-mytouch

This looks like the ideal and maybe typical case for carriers: very large number of subscribers (T-Com USA has more than 50 million customers, or so), big network which spans the entire continent, and squeezing all this into a set of IPv4 address ranges is just expensive trouble waiting to happen. T-Com can make that switch rather easily, as customers can replace their gear within 1-2 phone product cycles (1-2 years, probably less).

If the customers use the phones provided by T-Com, replacing the phones that don't do well in an IPv6 environment becomes even more convenient. The customers may not even notice the cost for the phone replacement because it happens along the normal technological upgrade path (say, you keep your iPhone for two years and trade up for the new model).