Daily Archives: September 16, 2019

[2019 oracle code one] advances in java security

Posted on by
Reply

New Security Control Enhancements – Java 9-12

Speaker: Jim Manico @manicode

For more blog posts, see The Oracle Code One table of contents


JEP

  • JEP = JDK Enhancement Proposal
  • Formal process
  • A lot of work

Crypto

  • See https://java.com/en/jre-jdk-cryptoroadmap.html (java.com/cryptoroadmap redirects here)
  • Java 8 had a lot of changes and enhancements
    • Ephermal cipher suite – rotates keys regularly
    • Better random number support
  • Consider third party libraries for crypto. Key management is hard. Want keys stored in vault. Your code should never touch the key.

Java 9 : JEP 290 – Filter Incoming Serialization Data

  • When you shut down Tomcat, it is serializes everything including sessions into files. When start up Tomcat, it deserializes.
  • Don’t deserialize anything untrest.
  • Can inject malware, read any file, run any OS command
  • Research talked about problem in 2011
  • Learned about problem in 2016 with Apache Commons Collections Gadget
  • Better to use JSON/XML
  • JEP-290 – ObjectInputFIlter interface. Validates classes before deserialization. Validates array sizes and deserialization limits
  • jdk.serialFilter – can specify limits
  • Was backported all the way back to Java 6

General notes

  • In 2017, “friday the 13th json attacks”
  • Turn off features not using: ex: XML DTD parsing
  • Patching critical. Ex: Jackson in last 18 months
  • Live attacks start within hours of framework/library security announcements
  • Security knowledge becoming more specialized. 20-30 people know spring security really well

Other Java 9

  • JEP 273 – Deterministic Random bit generator – as good as can get in Java
  • JEP-287 – SHA-3
  • etc

TLS Benefits (https)

  • Confidentiality – can’t view data
  • Integrity – can’t change data in transit
  • Authenticity – ensure site think visiting is the right one
  • Use everywhere
  • Internal apps can be easy attack vector if don’t use TLS/HTTPS
  • Symmetric key exchange fast
  • Asymmetric is slow. Used for authentication and key exchange. That way the symmetric key is exchanged asymmetrically.
  • All versions of SSL are dead at this point. TLS 1.0 is also dead.
  • Credit card processor charges higher fees if use old TLS version.
  • TLS 1.2+ encouraged. 1.3 is widespread
  • Test at server at https://www.ssllabs.com

Java 10

  • JEP 319 – open sourced core root certs. Now OpenJDK and Oracle JDK use same certs. Had to sign Oracle’s contributor agreement

Java 11

  • JEP 324 – Curve25519 and Curve448. More efficient and security. Important in Europe because NSA involved in prior versions.
  • JEP 319 – ChaCha20 is a new stream cipher. Poly1305 is one time authenticator. Combined they provide an AEAD algorithm. (authenticated encryption.) Again important outside US because can’t export ciphers to embargoed countries. Some US customers adopt as well.
  • JEP 332 TLS 1.3 – Much faster. Easier to configure. Old ciphers removed. Didn’t add much, but took a lot away. Supported by Chrome 65+, Edge 76+, Safari 12.1+ and Firefox 52+

Java 12

  • No JEPs
  • Many small enhancements like the keytool and SecurityManager

Java 13

  • No JEPs
  • Many small features.
  • Support Microsoft Cryptography Next Generation API

My take

I wish this talk was earlier in the day when my brain was working better. The concepts were good. I think the details were lost on me because Jeanne == morning person. That said, I learned a bunch of stuff and I’m glad I stayed for it! I really liked having the JEPs as reference numbers

[oracle code one] maven bof

Posted on by
Reply

For more blog posts, see The Oracle Code One table of contents

Discussion based. Key points:

  • 3.6.2 – some people were able to reduce memory consumption a lot. Four times less
  • 3.6.2 – environment variables in toolchain, not just settings.
  • Future: specify if want to fail on warnings (default to warn on warn)
  • CI: clean out workspace vs maven clean. Maven clean avoids pulling code again or if have local repo in workspace
  • Latest maven compiler will remove class files if sees change. Then recompiles
  • Some projects call plugins without understanding what do. Some can be unused code.
  • ”90% issues are people adding stuff don’t need”
  • Fabric 8 plugin – can generate and deploy docker images
  • Visual tool to show the build plan https://github.com/jcgay/buildplan-maven-plugin

My take

Any session where I have “homework” (something to try) is a good one in my mind!

[2019 oracle code one] maven stories

Posted on by
Reply

Broken Built Tools & Bad Habits: The Maven Stories

Speaker: Robert Schoite @rfschoite

For more blog posts, see The Oracle Code One table of contents


General

  • Instructions change over time and following practices from prior generations can get you in trouble.
  • Advice from Maven 1 and 2, may not apply to Maven 3
  • When learn new things – analyze, google/stack overflow, ask colleagues
  • When things fail – do three things when learning. Or can fix, create workarounds.
  • Workarounds tend to turn into a pattern
  • CI server is the neutral judge. Counter to “it works on my machine”
  • Apache tests latest Maven 3.0, 3.2, 2.3, 3.5 and 3.6 with java 7. And 3.6.1 with Java 7, 8, 11, 12 and 13 early access. Test on Ubunto and Windows

Why it works on your machine but not server

  • Changed code
  • OS – ex: Windows not case sensitive
  • JDK
  • Version of Maven
  • Files – regular files/directories
  • Properties – system/environment

Options to troubleshoot

  • -v version of Maven
  • -V version info and run build. Good for running on CI server
  • -e execution error messages
  • -X execution debug info

Local repo

  • No TTL (time-to-live)
  • Maven 2 – dumb cache
  • Maven 3: _remote.repositories – verify cached artifacts still exist
  • Designed for single user. CI server can be multi user and corrupt files due to concurrent writes/reads
  • Takarai Concurrent Local Repository – adds file locking to repo
  • Checksums not verified by default. -C is for strict checksums to fail if don’t match or -c for lax checksums to warn if don’t match. Shouldn’t be a problem now since binary repos have checksums. In Maven 4, will probably turn on by default.
  • Maven 2 and 3 share directory. In future, might separate SNAPSHOTS or by different remote repos

Multi modules

  • In Maven 2, not aware of reactor. Dependencies had to exist in local repo
  • Maven 3 is reactor aware so shouldn’t need install anymore. [for this scenario]
  • Can use installAtEnd/deployAtEnd experimental feature to wait until the last module runs

Flow

  • Locally run mvn verify
  • On CI Server, run mvn deploy. (hard to write without install so that is fine too)
  • This technique means all SNAPSHOTS are served by repo manager

Performance

  • Aim for clean Maaven output
  • Don’t write to System out/error
  • Don’t log during testing loglevel = off
  • Can set Maven flag to quiet if needed

Files

  • Replacing files is a waste
  • Most plugins can handle incremental execution
  • Avoid maven clean because forced rework
  • He wrote a plugin to nag you about using clean and install

Properties

  • Don’t change version of Java or a dependency on the command line

Versions

  • Maven 3.5.0 comes with CI friendly placeholders. Can specify revision, sha1 or changelist in version #. Ex 3.1.0-JIRA101-SNAPSHOT
  • Need relative path or GAV when building. Dependencies must use GAV
  • Maven 3.7 will probably require Java 8+

My take

This was good. Assuming you are familiar with Maven, there was a lot of info covered quickly but not hard to understand. If you don’t know Maven, I suspect this would have gone over your head. I learned a few new things so I’m happy.