WebSocket

[Chuck Davis]

James, who taught you how to ruin other people's days?  You seem to have
mastered the art......��

There seems to be a move afoot to abandon serialization.....hummm.  Then it
needs to get fixed because converting everything to a text stream before
transmitting is not an option (for me at least).  Then it needs to be
converted back to an object to play nice with Java when it reaches the
client.  I just did a quick look and there are no JSON classes in jdk9.  I
hope I never have to stoop so low as to use the HTTP protocol.  If so, I
want it to be under the covers where I never have to see it.

I'm going to continue to pursue my course because I have a fairly secure
environment.  I'll never bring in anything through the firewall.  All my
serialization is done in an ejb container with my specific versions of
commonly defined classes on both server and client and only one class can
ever be deserialized (although it is a container for other specific
classes).  If something else was going to be injected it would have to be
between the ejb container and my user's JVM which in my naivety seems quite
unlikely.  If the result does not conform to my class definition things
should blow up.

That said, I do need to study some on reactive streams since it seems to be
the future.

Thanks for the info and the links to more info.



On Sun, Feb 18, 2018 at 2:42 PM, James Roper <james at lightbend.com> wrote:
> Hi Chuck,
>
> Let's just imagine that for a moment that there existed a reactive streams
> equivalent to an ObjectReader (there isn't, and there's good reason why
> there isn't, but I'll get to that later). Then, the code would be
something
> like this (the Source API there is an Akka Streams like API):
>
> HttpRequest.create(URI.create("..."))
>   .GET()
>   .response((status, headers) ->
>       BodySubscriber.from(
>         Source.asPublisher()
> Now, as I said, no reactive streams implementation (that I'm aware of)
> provides Java serialization support, and for good reason. It's 2018, Java
> serialization has been shown, time and time again, to have major security
> flaws in it. If you make an HTTP request on another application, and parse
> what it gives back to you using ObjectInputStream, you are opening a quite
> trivial way for that application to execute code on your application. Even
> if you trust the remote system, it goes against the security best practice
> of bulkheading - ensuring that if one application is compromised, the
entire
> system isn't compromised. No one wants to provide support these days for
> such insecure practices.
>
> Here's a good summary of why you should never use Java serialization:
>
> https://www.christian-schneider.net/JavaDeserializationSecurityFAQ.html
>
> Regards,
>
> James
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20180218/61290ffe/attachment-0001.html>