Announcing Play 2.2.3

[James Roper]

Hi All,

The Play team are pleased to announce the release of Play 2.2.3!

This release is primarily a bugfix release, but it also contains one security fix, see here for more details:

https://groups.google.com/d/msg/play-framework-security/ZWW0YzRnbHs/sN4qBVlbfkUJ

The issues fixed in this release are:

• 2508 Gracefully handle bad URIs in request by returning 400 errors.
  
• 2499 When validation fails for a Java form, don’t render duplicate repeat elements.
  
• 2535 Ensure exceptions thrown by JUnit get logged.
  
• 2509 Make WS SSL requests use a hostname verifier by default.
  
• 2683 Continuation frame handling for WebSockets
  

For more details you can visit our changelog.

This release can be downloaded from:

http://downloads.typesafe.com/play/2.2.3/play-2.2.3.zip

Enjoy!

-- 

James Roper
Software Engineer

Typesafe – Build reactive apps!
Twitter: @jroper

JOIN US. REGISTER TODAY!

Scala

Days

June 16th-18th,

Berlin

[Adis]

Good job! Thanks!

[Yann Simon]

2014-05-01 4:10 GMT+02:00 James Roper <james...@typesafe.com>:
> Hi All,
>
> The Play team are pleased to announce the release of Play 2.2.3!
>
> This release is primarily a bugfix release, but it also contains one
> security fix, see here for more details:
>
> https://groups.google.com/d/msg/play-framework-security/ZWW0YzRnbHs/sN4qBVlbfkUJ
>
> The issues fixed in this release are:
>
> 2508 Gracefully handle bad URIs in request by returning 400 errors.
> 2499 When validation fails for a Java form, don’t render duplicate repeat
> elements.
> 2535 Ensure exceptions thrown by JUnit get logged.
> 2509 Make WS SSL requests use a hostname verifier by default.

Nothing really serious, but this change breaks an application.
This application is configured to accept any certificate
(ws.acceptAnyCertificate=true)

Nevertheless the certificate is now check:
10:49:30.003 [warn] o.j.n.channel.DefaultChannelFuture - An exception
was thrown by ChannelFutureListener.
java.net.ConnectException: HostnameVerifier exception.
at com.ning.http.client.providers.netty.NettyConnectListener.operationComplete(NettyConnectListener.java:81)
~[async-http-client-1.7.18.jar:na]
at org.jboss.netty.channel.DefaultChannelFuture.notifyListener(DefaultChannelFuture.java:427)
~[netty-3.7.1.Final.jar:na]
at org.jboss.netty.channel.DefaultChannelFuture.notifyListeners(DefaultChannelFuture.java:413)
~[netty-3.7.1.Final.jar:na]
at org.jboss.netty.channel.DefaultChannelFuture.setSuccess(DefaultChannelFuture.java:362)
~[netty-3.7.1.Final.jar:na]

The WS request never completes.
Is that the expected behavior? Or should an exception be thrown to the callee?

As quick workaround, it is possible to configure an non existing
hostname verifier:
ws.ssl.hostnameVerifierClassName=blabla

Maybe the hostname should not be verified when the WS is configured to
accept any certificate?

Cheers,
Yann

> 2683 Continuation frame handling for WebSockets
>
> For more details you can visit our changelog.
>
> This release can be downloaded from:
>
> http://downloads.typesafe.com/play/2.2.3/play-2.2.3.zip
>
> Enjoy!
>
> --
> James Roper
> Software Engineer
>
> Typesafe – Build reactive apps!
> Twitter: @jroper
>
> JOIN US. REGISTER TODAY!
> Scala
> Days
> June 16th-18th,
> Berlin
>

> --
> You received this message because you are subscribed to the Google Groups
> "play-framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to play-framewor...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Will Sargent]

Nothing really serious, but this change breaks an application.
This application is configured to accept any certificate
(ws.acceptAnyCertificate=true)

Nevertheless the certificate is now check:
10:49:30.003 [warn] o.j.n.channel.DefaultChannelFuture - An exception
was thrown by ChannelFutureListener.
java.net.ConnectException: HostnameVerifier exception.
at com.ning.http.client.providers.netty.NettyConnectListener.operationComplete(NettyConnectListener.java:81)
~[async-http-client-1.7.18.jar:na]
at org.jboss.netty.channel.DefaultChannelFuture.notifyListener(DefaultChannelFuture.java:427)
~[netty-3.7.1.Final.jar:na]
at org.jboss.netty.channel.DefaultChannelFuture.notifyListeners(DefaultChannelFuture.java:413)
~[netty-3.7.1.Final.jar:na]
at org.jboss.netty.channel.DefaultChannelFuture.setSuccess(DefaultChannelFuture.java:362)
~[netty-3.7.1.Final.jar:na]

The WS request never completes.
Is that the expected behavior? Or should an exception be thrown to the callee?

As quick workaround, it is possible to configure an non existing
hostname verifier:
ws.ssl.hostnameVerifierClassName=blabla

Maybe the hostname should not be verified when the WS is configured to
accept any certificate?

They are different things.  

Accept Any Certificate will allow any given X.509 certificate to be treated as if it is signed by a trusted certificate authority.

Hostname verification says “this certificate contains the same DNS name as the URL that I am connecting to.”

Wrote a couple of blog posts on it, since it’s not as well known as it should be (it’s technically part of HTTPS, not TLS):

http://tersesystems.com/2014/03/23/fixing-hostname-verification/

http://tersesystems.com/2014/03/31/testing-hostname-verification/

Will.

[Yann Simon]

Thanks about this detailed info, Will.
What about the request that never complete with that verification? Is it the expected behavior?

[Will Sargent]

Thanks about this detailed info, Will.
What about the request that never complete with that verification? Is it the expected behavior?

If a TLS connection cannot be verified with the hostname, the RFC says that the connection should be terminated.  The paper “The Most Dangerous Code in the World” goes into this in more detail, with an explanation of why disabling hostname verification in TLS is a real and serious risk.

https://security.stackexchange.com/questions/22965/what-is-the-potential-impact-of-these-ssl-certificate-validation-vulnerabilities/23003#23003

Will.

[Yann Simon]

Great to see that security is taken seriously
I just think that the "ops" experience could be improved a bit:
- the error is just logged as WARN. I expect in that case that the
process continue.
- the error does not tell which hostname could not be checked, making
it difficult to analyse in production.
- it would be great that an exception is thrown to the action, letting
the action a chance to deal with the error. The current behavior to
let the browser waiting indefinitely is not so great IMHO.

Yann

[James Roper]

The fact that the promise never completes with a failure is a bug.  Please raise something in the issue tracker for this.

--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framewor...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Yann Simon]

2014-05-04 10:14 GMT+02:00 James Roper <ja...@typesafe.com>:
> The fact that the promise never completes with a failure is a bug. Please
> raise something in the issue tracker for this.

https://github.com/playframework/playframework/issues/2767

[Jxtps]

For anyone running into "org.jboss.netty.handler.codec.frame.CorruptedFrameException: Max frame length of 65536 has been exceeded" with 2.2.3, note that

  https://github.com/playframework/playframework/blob/master/framework/src/play/src/main/scala/play/core/server/netty/PlayDefaultUpstreamHandler.scala#L223

sets the default of the new configuration parameter "play.websocket.buffer.limit" to 65536L

You may need to increase it if you're using very large messages.

Most unfortunately those exceptions do not percolate up to user code, so it's hard to detect
& react (we send emails when there are exceptions, otherwise they tend to get lost in the logs).

Also, when this happens, the connection is forcibly closed, which is fine, except that when I
then try to send a message from the server to the client over the now closed connection there
is a java.nio.channels.ClosedChannelException that goes into the log, but again does not reach
user code, despite user code being in the call-stack and having try-catch around it.

The problem is very easy to reproduce - in your websocket application, just set
play.websocket.buffer.limit to something really small, like 10 or so.

[James Roper]

This is actually a small part of the security issue - because previously it was unlimited, an attacker could trivially DoS your server.

As for sending emails in response to these exceptions - protocol level exceptions like this could be caused by anything, for example, it could be a client sending malformed data, or a bot scanning the web for vulnerabilities.  Especially if your server is internet facing, most people don't want to get emails just because a bot came and tried to detect whether the server was vulnerable to something (which on the low traffic servers that I run, such as my own domain, tends to happen many times per day).

If you really like to be spammed by your servers, then you should define a custom logback appender, then you can email everything.

Also when you write to a response, and the channel is closed, this is also something that you don't typically want user code to handle, as this is exactly what would happen if, for example, a user closed their browser mid download, or if the users network connection suddenly dropped (very very common for mobile devices).  Again, I definitely would not want an email every time these events happen.

--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framewor...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

James Roper
Software Engineer

Typesafe – Build reactive apps!
Twitter: @jroper

SEE YOU IN BERLIN