Amiga.org
Amiga computer related discussion => Amiga Software Issues and Discussion => Topic started by: slaapliedje on October 19, 2014, 08:43:20 PM
-
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
-
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.
AmiSSL is OpenSSL with Amiga library structure i.e. it is shared library. Amiga OpenSSL project is just recompile of OpenSSL with less tweaks and statically linked.
I think AmiSSL project is pretty much dead. Amiga OpenSSL on the other hand requires recompile of binaries i.e. not going to happen.
-
AmiSSL is OpenSSL with Amiga library structure i.e. it is shared library. Amiga OpenSSL project is just recompile of OpenSSL with less tweaks and statically linked.
I think AmiSSL project is pretty much dead. Amiga OpenSSL on the other hand requires recompile of binaries i.e. not going to happen.
Just got referred to this thread by asking similar question on Amigaworld.net, tried both amissl and openssl as is with no success.. (Not surprised either, though). Hoping something can be patched up so this will work again, would offer to compile this stuff, but my skills with a compiler are a bit rusty.
-
I think AmiSSL project is pretty much dead. Amiga OpenSSL on the other hand requires recompile of binaries i.e. not going to happen.
I hope that you're wrong about AmiSSL being dead. With the SSL "poodle" vulnerability, SSL3 is set to be disabled on the bulk of servers on the internet. So, the current AmiSSL version is set to become pretty useless.
On AmigaOS4, an updated OpenSSL shared object could be compiled (for those programs that use shared objects), but a shared library really is the right way to go.
However, I notice that the last commit to the AmiSSL repository was about a month ago. So, maybe it's not dead after all...
Hans
-
I was thinking about making shared library from openssl but it is impractical in many ways. API is unstable and changes from version to version and I would have to change library name every time it becomes incompatible. Then it is also easy to make small mistake in transforming build to shared library and introduce bugs that would not be there in static build. And last but not least if there are any changes to openssl code base users must wait until changes are merged and new library is built. That could take only few minutes at best but developers are not on call 24/7.
On the other hand if developers just use statically linked openssl it is more robust and security fixes can be applied without relying on other party updating library code.
It is neat idea but I am now just happy I didnt go there.
-
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.
-
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
-
That's a great idea, Buzz. I know one of the goals of LibreSSL is to make the code base a lot smaller, but then I think a lot of the work they've been putting into that involves dropping support for legacy systems like VMS. Not sure if Amiga was on that list.
slaapliedje
-
That's a great idea, Buzz. I know one of the goals of LibreSSL is to make the code base a lot smaller, but then I think a lot of the work they've been putting into that involves dropping support for legacy systems like VMS. Not sure if Amiga was on that list.
You should also consider how rigorously the code is checked for bugs, and how quickly problems are patched. Given that we're talking about a protocol for secure communications, we don't want to end up with something that has known exploits that aren't fixed quickly enough.
Hans
-
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 :(
-
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 :(
True, and it is also the same with programs linked against openssl, like OWB.
-
You should also consider how rigorously the code is checked for bugs, and how quickly problems are patched. Given that we're talking about a protocol for secure communications, we don't want to end up with something that has known exploits that aren't fixed quickly enough.
do some reading up on polarssl then? it is certainly in active development. It is supported by some well known software - openvpn, curl, etc.
[edit] sorry I think I misread - you are referring to the libressl fork ?
-
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.
the software could be adapted I guess, if still in development. Anyway, I was just throwing ideas out there. adapting software to use the polarssl api is not too tricky, if the source is available - unfortunately not the case very often in amiga land (Check projects like curl, librtmp, openvpn which support both). There is at least one other ssl solution out there that has an openssl compatible api - cyassl I think
polarssl is still far more suited to the amiga than openssl, and a lot easier to build/adapt.
-
Looks like polarssl does have an openssl wrapper - not sure if it is up to date/working/maintained - but if it works it would make keeping the api compatible easier.
-
do some reading up on polarssl then? it is certainly in active development. It is supported by some well known software - openvpn, curl, etc.
[edit] sorry I think I misread - you are referring to the libressl fork ?
I wasn't referring to anything in particular, but did have the libressl fork in mind. It sounded like a lapse in code review process may have allowed the heartbleed vulnerability into OpenSSL, which is the kind of thing that we want to avoid.
I have no idea about the coding standards of the other SSL implementations, but do think that this is worth considering. Something as critical to security as SSL needs a more rigorous development process than your typical application.
Hans
-
In the meantime is there a workaround for Ibrowse and such? I've tried using Privoxy and AnalogX proxy servers on a win7 machine, but they both seem to "properly" route https stuff (pass the encrypted data through so the Amiga can decode it, which right now it can't). Perhaps something that decodes on the host machine and passes the decoded stuff to Ibrowse (or aweb/netsurf/etc...)?
-
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.
-
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.
-
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.
-
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??
-
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.
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.
-
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.
-
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).
-
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.
-
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.
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!
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?
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...
-
Exactly what Olsen said about IPv6, but that's not what this topic is about, it's about being able to see some sites with Amiga browsers (I know, it's weird to think we should try to make things compatible with such old things) but still something as basic a necessity as TLSv1.1 support is something I'd hope would be fairly easy to add to which every implementation is currently still being developed.
Most web servers (if they care about their clients) will start forcing at minimum TLSv1.1 (still seems to be things on the fence whether or not TLSv1.0 is vulnerable to the 'poodle' style attack. Red hat sure thinks it is).
The biggest problem with 'well who cares it's just Amiga' is that if people are completely unaware of this issue, they will think their information is secure when it really isn't. Granted you'd have to be pretty hard core to only browse the Internet with an Amiga, but I'm sure there are some of you out there that do. :D
I'm going to go with a car analogy here... even though they're usually horrible. Let's say they started coating specific roads for self driving cars. Of course only fancy rich folks can drive on those. Well all the stores move to those roads because that's where the money is at. While those with Dodge Dusters and sell women's shoes are stuck having to go to the crappy mall where they get mugged on a daily basis. Cops are all paid by the rich, protecting their self-driving cars.
That's pretty much the Amiga. It's a high pitched woman always spending your money, so you're stuck driving a duster to the mall to sell shoes. :D
slaapliedje
-
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.
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!
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?
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...
Well, sure they probably have it enabled by default, but it's not like they prioritize IPv6 over 4. And I'd like someone to name a single IPv6 only device. Really, I'd like to know if one exists.
You know, there's this thing called NAT... and how does having an ancient DHCP implementation affect anything but the Amiga? It still works fine with my isc-dhcp-server I'm running on my Debian box. Either way, all of this is irrelevant to the topic at hand of getting newer SSL.
slaapliedje
-
The ignorance here is frustrating, would be nice if people could read up on the topic.
Yes, any dual stack implementation prioritize IPv6 over IPv4 - that is how it is supposed to work - a host does DNS lookup and if AAAA record exists, that will be used first, and if connection fails it will try the A record. OSX for a long time chose any record it received first from the lookup, but they have fixed that. Smaller devices should not have the overload of full dual-stack, so DS-lite (yeah, ha ha) was developed, that helps them reach IPv4 hosts even though they are primarly IPv6 only.
Any device that is dual stack is also ready to be IPv6 only, and since IPv4 address space is nothing short if being used up, and the IPv4 routing tables get bigger and bigger due to the fragmentation, IPv6 more and more emerges as the cheap and easy way out - when that happens it is bye-bye IPv4 for most ISPs.
NAT wont help you squat, there is NAT64 that today helps people to run IPv6 only LANs to reach IPv4 services, which many wireless providers already do, especially ar universities where thousands and thousand of devices are hooked up at once. Other likely IPv6 devices are cable TV boxes, I know ComCast at least are working a lot with IPv6 in their TV boxes.
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.
-
Fittefaen, when did amiga.org start with sensoring, how utterly lame.
-
My point is that, since noone even cares about fixing the situation of the IP stack, I see little point in fixing the SSL situation. And regardless, AmigaOS was not developed with security in mind - _any_ crypting solution on Amiga systems is nothing but FAIL, since any program can sniff around anywhere in the memory. I don't know if MorphOS or OS4 developers take measures, using MMU for example, to sandbox and protect memory where decryptet data is stored, but for sure on AmigaOS this is not the case.
-
My point is that, since noone even cares about fixing the situation of the IP stack, I see little point in fixing the SSL situation. And regardless, AmigaOS was not developed with security in mind - _any_ crypting solution on Amiga systems is nothing but FAIL, since any program can sniff around anywhere in the memory. I don't know if MorphOS or OS4 developers take measures, using MMU for example, to sandbox and protect memory where decryptet data is stored, but for sure on AmigaOS this is not the case.
Sure, the local security will be the weak point in the chain, but SSL/TLS still prevents communications from being snooped on as the packets are relayed through the internet. Plus, there's a slow trend toward websites being HTTPS only (Google's pushing for this).
Hans
-
Of course, I'm just saying that a browser running on an amiga like system is an easy target for abuse, even when https is used.
Regarding IPv6, I checked with peers on an IPv6 forum to make sure there's nothing I have overlookef, and they all agree with me. Only solution would be a stateful NAT46/DNS46 implementation, something that has not been done yet, and it would be very cumbersome and inpractical since you simply cannot map 128bit address space into a 32bit address space. And do no expect ISPs to fix this, they are steadily moving towards IPv6 only to customers, many of them already use IPv6 only for management. It is coming and sooner than you think now.
-
Okay, so Amiga TCP/IP is aged. Does it still work? Will it work for a while? At least long enough to ensure that data in-transit is secured? At this point in the real world if the consensus is that Amiga should isolated from the Internet due to existing network deficiencies and should never be fixed, you might as well just wrap it up and put it in a box forever. If a platform is going to be useable for more than just game playing, arguably out-dated graphic design, and word processing, it must have access to the outside world. Anything is programmatically possible -- hell, you could implement SSL in 6502, it just might be unusably slow, but still possible -- so saying that something is "FAIL" or useless should not imply nor be inferred that it should not be done.
All things considered, I couldn't give two rats turds about IPv6. That bell has been ringing for over 14 years and it's still just piss in the wind. As it is, I can route my IPv6 network through an 6-to-4 gateway at Hurricane just fine. Should we expect that the reverse will never be possible? The experts out there may not think so or may not want it, but the market of users with older equipment not willing or able to upgrade will make that decision. And where the market bucks the experts there is money to be made, so I suspect entrepreneurs will help fill the void.
(FWIW, since my network has a unified threat management device (they're really cheap these days, along the same price as any good business-class non-UTM firewall,) all of my secure connections are decrypted at the firewall which then makes the secure connection to the far end. So for me the SSL/TLS issue is moot as the firewall will ultimately determine security heading out into the world.)
But, again, the arguments of IPv6 and IPv4 are off-topic for this thread, which is about getting TLS v1.1 and v1.2 support on the Amiga.
-
Thank you to everyone who is not Kolla, who seem to support my thoughts.
For the record, 'they' really have been saying that for a very long time (14 years sounds about right). Hell, they were at least a few years ago that IPv4 was over, and everyone had to switch over to IPv6 NOW! What happened? Nothing. Even CenturyLink (my ISP) was saying that they were doing it... then when I tried to configure my modem to use IPv6, it simply didn't work. I finally managed to get it to work, so now both IPv6 and IPv4 work fine, and the whole reason NAT still works and will work forever is because you can easily have a firewall/router in place that will still translate your internal network for you so you can browse the Internet. There is no way they'll ever just drop that capability, because there are far too many systems out there that would simply stop working, and there are (non-US) countries out there who actually care about consumer rights.
It's like when Sony removed the Other OS option in the PS3. There was a huge uproar about that. Imagine if all IPv4 only devices stopped working on the Internet tomorrow?
Yes, back on topic, the support for newer versions of the SSL stack (TLS1.1 and TLS1.2) are simply needed for something that'll happen sooner than IPv6 only everywhere, and that would be HTTPS everywhere. I noticed amiga.org doesn't use https by default. I actually had to switch my server back to SSLv3 support, just so I could log into my webmail and get something I had ordered for my Amiga out of my email. (HSmathlibs) So yes, there is a reason for a networked Amiga. Could I have dropped it into an NFS share or an FTP server? Sure. It was more convenient to read it straight out of my email though.
This is pretty typical though of a lot of Amiga-related discussions. "Well who cares, I don't use that anyhow, and it's old, let it die!" Well, I am pretty sure the same SSL stack is used on OS4 and MorphOS, so wouldn't they really want to fix this?
slaapliedje
-
Regarding IPv6, I checked with peers on an IPv6 forum to make sure there's nothing I have overlookef, and they all agree with me. Only solution would be a stateful NAT46/DNS46 implementation, something that has not been done yet, and it would be very cumbersome and inpractical since you simply cannot map 128bit address space into a 32bit address space. And do no expect ISPs to fix this, they are steadily moving towards IPv6 only to customers, many of them already use IPv6 only for management. It is coming and sooner than you think now.
I recently read an article in an IEEE magazine about IP protocol extensions that adds several billion addresses in a way that's backward compatible to existing IPv4 stacks. I think that they're all based on this doc (https://tools.ietf.org/html/draft-ymbk-aplusp-10), but I can't find the article. These extensions could keep IPv4 running for a while longer while they wait for IPv6 to be more widely deployed.
Hans
-
I say we take this into consideration. HTTPS everywhere is most likely to happen far sooner than IPv6 only, especially in light of extensions like that. So we figure out how to fix AmiSSL (or other project), then work on getting IPv6 working.
While of course we get NetSurf (or other) to work with native widgets (MUI?). Would be sweet if we at least had some basic CSS support, which seems to be the way a lot of the Web is going.
As long as pages aren't using really heavy javascript, then even ibrowse is pretty fast. After I finally got my Amikit for Real set up on my A4000D, it loads pages really fast, as long as there isn't any heavy javascript.
slaapliedje
-
This is pretty typical though of a lot of Amiga-related discussions. "Well who cares, I don't use that anyhow, and it's old, let it die!" Well, I am pretty sure the same SSL stack is used on OS4 and MorphOS, so wouldn't they really want to fix this?
It is already fixed. OWB is using rather decent openssl 1.0.1g
http://fabportnawak.free.fr/owb/owb-morphos-1.24.readme
Like I said when it is a link library changes can be quickly adopted to the software. AmiSSL way is neat but shared libraries need more testing and active maintainers.
So my suggestion is software developers should not use AmiSSL anymore but use openssl or similar library directly. You get security fixes sooner, you cut development time and you achieve same results.
-
It is already fixed. OWB is using rather decent openssl 1.0.1g
http://fabportnawak.free.fr/owb/owb-morphos-1.24.readme
Like I said when it is a link library changes can be quickly adopted to the software. AmiSSL way is neat but shared libraries need more testing and active maintainers.
So my suggestion is software developers should not use AmiSSL anymore but use openssl or similar library directly. You get security fixes sooner, you cut development time and you achieve same results.
Good to know, whatever happened to the port of OWB to 3.9/m68k? I know there is an earlier build of it, but it was horribly broken last time I tried it.
slaapliedje
-
Good to know, whatever happened to the port of OWB to 3.9/m68k? I know there is an earlier build of it, but it was horribly broken last time I tried it.
OWB relies heavily on MUI4 so it is not easy to port it to 3.9. It would need someone who know MUI quite well. And you have to get latest openssl compiled. It should be fairly easy (I suppose so) but all those little details add up.
Problem with 68k Amiga is there is no team maintaining development system and APIs are not actively updated. So this topic, AmiSSL / OpenSSL updates comes to the fact that we (well, you) need a team behind Amiga.
-
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
I'm going to see if I can create a cross compiling environment (first, seems easier than getting a compiling environment under the Amiga itself). Then compile it and test it out.
Anyone try this?
http://fengestad.no/m68k-amigaos-toolchain/
slaapliedje
-
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.
-
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.
-
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.
-
Found a work-around (granted, and ugly one) for ssl right now. I was able to log into Facebook (one of the sites that Ibrowse chokes on) with Icab 2.9.9 running on shapeshifter. ( http://www.icab.de ) Netscape didn't work, though. This requires a pretty heavily upgraded Amiga to do well, though.
-
OK, just tried using Aweb to log into Facebook ( m.facebook.com ), and it worked. Though, the os3.9 version of Aweb seems to work while any I've downloaded doesn't for some reason. Wish Ibrowse could be made to work though, because its alot faster. With this working right on an Amiga browser, perhaps a general https: proxy server compiled for AOS would work?
-
Olsen, clearly you do not understand that the transition is already happening, and it is IPv4 that is left behind. Here is an example of what is going on...
https://sites.google.com/site/tmoipv6/lg-mytouch
-
https://wiki.debian.org/DebianIPv6
I figure all I'd have to do for when / if IPv4 ever goes away, is to set up a relay router as per that wiki page. But there isn't really a way for https to work this way, unless I attempt to do some sort of proxy configuration, which decrypts the info in the proxy and allows the Amiga to display it. This is possible, but not very 'secure'.
slaapliedje
-
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).
-
@thread
Some good news on AmiSSL4.
I recently communicated with Jens Maus on the status. He hopes to have this out by the end of November. This includes bringing in the most recent OpenSSL patches.
This isn't a promise but fingers crossed we see this by the end of the year. This is a multi-platform release (68K, OS4, MorphOS, AROS).
Here is the Github page: https://github.com/jens-maus/amissl
-
Wow! Great news !
-
i'll second that - significant, brilliant news!
-
Awesome! One of the key components of keeping the Amiga 'modern'.
With how many systems the upstream source supports, I'm honestly surprised the ever dropped support for Amiga. I think it still has support for some really old systems, which is why a lot of it was ditched while making LibreSSL from what I'd read.
-
Very exciting, indeed. This re-opens much usability with Amiga Internet utilities.
-
While this is good news, keep in mind a new AmiSSL won't fix the problems we have now.
Also the applications (browser, ftp client) using AmiSSL need to be updated in order to support TLS 1.x
-
Sounds really promising!! Looking forward to this new release. Fingers crossed!!
-
Just saw this on Aminet:
http://aminet.net/package/util/libs/AmiSSL-3.6-68k
Has anybody tried it yet? How's it work?
-
@Oldsmobile_Mike
isn't that the release from 2006, though?
-- eliyahu
-
I don't pretend to know. It was uploaded 11/5/2016.
-
I uploaded the package and it is the old one. Just wanted to make it available through aminet.
-
Aww, boo. :(