Re: Taking Security Seriously
Hi The attack scenario that I'm trying to guard against is the following: Stopping an attacker that manages to exploit the our nexus server from being able to run arbitrary code on all the build servers and developer machines in our organization. best regards Alexander Kjäll On 06. des. 2016 13:25, Tibor Digana wrote: What real problem is behind your question? Are you running any tool which has a problem with signatures in Nexus or the development process in your company has a problem? The MD5 is not security nothing but verification of deployed artifact is identical binary you have downloaded from Nexus, and however GnuPG *.asc is the real signature of deployer and the KEYS can be found in Apache projects if really necessary. You should be always able to verify gpg signatures via (gpg --verify your-artifact-file.sig your-artifact-file) without adding (XXX) in POM. On Mon, Dec 5, 2016 at 1:56 AM, John Patrick wrote: Hiya, So currently checksum's are not generated by default... I've submitted a ticket which switched the install plugin to generate them by default. Next step stop using md5 which most have considered dead for several years, and checking apache (https://www.apache.org/dev/release-signing.html) sha512 should be being used. So either; 1) add support so md5, sha1, sha256 and sha512 are all generated 2) plugin defines which is generated 3) plugin defines a list which are generated 4) settings.xml defines which is generated 5) settings.xml defines a list which are generated? Thoughts??? Next; Currently when downloading we have ignore, warn or error if checksum's don't match. I propose adding a checksum min level options? i.e. allow MD5 > SHA1, SHA256 > SHA512 So; 1) Default to MD5 2) Wait till all maven plugins deploy a sha512 to central 3) Switch default to SHA512 What are developers thoughts? What staged steps should this be merged as? I would like to start helping getting the core maven and all of it's dependencies more secure so people can start trusting maven is secure by default as I get the feeling isn't at the moment. Cheers, John - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Taking Security Seriously
This is a a good idea, and a hash it would serve roughly as good as specifying the key i think, it would maybe even be better since it's easier to generate a hash. It might be wise to plan for the future, as what ever hash algorithm that is considered best practice today will be broken and useless at some point in the future. maybe something like this: junit junit 4.12 XXX And having the signed-by element be legal to specify 0-N times, so that it's possible to add multiple versions of it but not required. I understand that .md5 files isn't used to verify that the downloaded artifact isn't controlled by an attacker, but at least I use the .asc files for that. Do you mean that they also have some other purpose? best regards Alexander Kjäll On 05. des. 2016 23:10, Bernd Eckenfels wrote: Having artifact checksums (hashes not signatures) in POM dependency declarations would be cool, but that is not what .md5 or .asc is used for. Gruss Bernd - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Taking Security Seriously
Maybe we are talking about different attack scenarios? The vector I would like to protect against is that someone is able to inject false binaries in a caching nexus server (or over the network if https is not used). The way I envision the trust to be established is: The developer goes either to maven central or the projects homepage and copies the block needed to add the dependency to pom.xml. The dependency block includes information that can be used to cryptographically guarantee that the binary that ends up in the build is the same one that the original developer published. I think it would be possible to simplify the verification of gpg signatures and make it be possible to automate it in a resonable manner. best regards Alexander Kjäll 2016-12-05 18:29 GMT+01:00 Hervé BOUTEMY : > I fear the proposed change would not improve security but lower it: > if the pom contains the reference to a key "to be used to sign the artifact", > anybody wanting to change the content will just change the key reference to a > value it owns > > yes, knowing which keys you should trust to sign which artifact is not easy, > but I fear there is no automagic way to automate trust > > What I'd want to do is to improve the dependencies report to show the key used > to sign the artifact: that would improve people knowledge of who they are > trusting: but that would not mean that they can trust them... > > Regards, > > Hervé > > Le lundi 5 décembre 2016, 09:31:20 CET Alexander Kjäll a écrit : >> Regarding verifying the gpg signature, as a contributor to the gpg >> verify plugin here: >> >> http://www.simplify4u.org/pgpverify-maven-plugin/index.html >> >> I have some thoughts on why the current infrastructure doesn't really >> help us to verify the signatures in practice: >> >> 1) Very hard to know what key are the correct one, as it's not specified >> anywhere in the pom, you need to contact the developer of the jar that >> you want to verify and ask them to publish what key they used to sign >> the project with. It would be nice to have a tag in the pom >> in order to resolve this. >> >> 2) Verifying the signature can't really be done with a maven plugin, as >> those are downloaded over the same channels that the jar's are >> downloaded over, and there is no method for maven to verify that it >> downloaded the correct plugin. >> >> I opened a bug about this problem a couple of years ago, but since it's >> not really possible to fix this without changing the structure of the >> pom i didn't even bother to write a patch for it. >> >> If there is a chance that a fix for this problem would be included, then >> I would be happy to try to write a patch for it. >> >> best regards >> Alexander Kjäll >> >> On 05. des. 2016 08:23, Hervé BOUTEMY wrote: >> > AFAIK, checksums are there only to avoid stupid download/upload >> > distorsion. >> > What gives real security is *signature* done by developers, ie .asc files, >> > that use other hash algorithms than these little .md5 and .sha1 files. >> > That's why we recommend to verify *the signature* [1]. >> > >> > Another topic: https://www.apache.org/dev/release-signing.html is not >> > about >> > Maven repository but is about Apache releases that are distributed as part >> > of Apache official (source) releases, distributed by Apache mirrors [2] >> > >> > AFAIK, security is taken seriously: checksums are just not really part of >> > that security, they are only checksums. >> > >> > Regards, >> > >> > Hervé >> > >> > [1] http://maven.apache.org/download.cgi >> > >> > [2] https://www.apache.org/mirrors/ >> > >> > Le lundi 5 décembre 2016, 00:56:22 CET John Patrick a écrit : >> >> Hiya, >> >> >> >> So currently checksum's are not generated by default... I've submitted >> >> a ticket which switched the install plugin to generate them by >> >> default. >> >> >> >> Next step stop using md5 which most have considered dead for several >> >> years, and checking apache >> >> (https://www.apache.org/dev/release-signing.html) sha512 should be >> >> being used. >> >> >> >> So either; >> >> 1) add support so md5, sha1, sha256 and sha512 are all generated >> >> 2) plugin defines which is generated >> >> 3) plugin defines a list which are generated >> >> 4) settings.xml defines which is generated >> >> 5) s
Re: Taking Security Seriously
Regarding verifying the gpg signature, as a contributor to the gpg verify plugin here: http://www.simplify4u.org/pgpverify-maven-plugin/index.html I have some thoughts on why the current infrastructure doesn't really help us to verify the signatures in practice: 1) Very hard to know what key are the correct one, as it's not specified anywhere in the pom, you need to contact the developer of the jar that you want to verify and ask them to publish what key they used to sign the project with. It would be nice to have a tag in the pom in order to resolve this. 2) Verifying the signature can't really be done with a maven plugin, as those are downloaded over the same channels that the jar's are downloaded over, and there is no method for maven to verify that it downloaded the correct plugin. I opened a bug about this problem a couple of years ago, but since it's not really possible to fix this without changing the structure of the pom i didn't even bother to write a patch for it. If there is a chance that a fix for this problem would be included, then I would be happy to try to write a patch for it. best regards Alexander Kjäll On 05. des. 2016 08:23, Hervé BOUTEMY wrote: AFAIK, checksums are there only to avoid stupid download/upload distorsion. What gives real security is *signature* done by developers, ie .asc files, that use other hash algorithms than these little .md5 and .sha1 files. That's why we recommend to verify *the signature* [1]. Another topic: https://www.apache.org/dev/release-signing.html is not about Maven repository but is about Apache releases that are distributed as part of Apache official (source) releases, distributed by Apache mirrors [2] AFAIK, security is taken seriously: checksums are just not really part of that security, they are only checksums. Regards, Hervé [1] http://maven.apache.org/download.cgi [2] https://www.apache.org/mirrors/ Le lundi 5 décembre 2016, 00:56:22 CET John Patrick a écrit : Hiya, So currently checksum's are not generated by default... I've submitted a ticket which switched the install plugin to generate them by default. Next step stop using md5 which most have considered dead for several years, and checking apache (https://www.apache.org/dev/release-signing.html) sha512 should be being used. So either; 1) add support so md5, sha1, sha256 and sha512 are all generated 2) plugin defines which is generated 3) plugin defines a list which are generated 4) settings.xml defines which is generated 5) settings.xml defines a list which are generated? Thoughts??? Next; Currently when downloading we have ignore, warn or error if checksum's don't match. I propose adding a checksum min level options? i.e. allow MD5 > SHA1, SHA256 > SHA512 So; 1) Default to MD5 2) Wait till all maven plugins deploy a sha512 to central 3) Switch default to SHA512 What are developers thoughts? What staged steps should this be merged as? I would like to start helping getting the core maven and all of it's dependencies more secure so people can start trusting maven is secure by default as I get the feeling isn't at the moment. Cheers, John - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Warning when artifacts are downloaded over an insecure channel
I tried to write a patch for this, and I don't think this is really possible to do without introducing some sort of state in order to avoid duplicate messages, I also ran into the issue that a repository definition might not be used as it might be overridden by another definition, so issuing warnings when repository objects gets created isn't really possible. After looking around a bit and trying different things I came to the conclusion that the listeners might be a resonable place to hold this state and issue warnings, that might of course be totally wrong as I'm not very familiar with the code. I attached a patch that added a hash of domains that there has been a issued a warning about, so that maven doesn't warn twice about the same domain. The hash is not threadsafe, because as far as I understood the code the listeners doesn't run in multiple threads. It issues one warning per unique hostname that it downloads from. //Alex 2016-10-08 12:03 GMT+02:00 Alexander Kjäll : > I liked the idea to only issue warnings about repository urls and not > for every download, that would greatly reduce the amount of duplicated > information. > > I think it might be user friendly to inform when someone has > configured their project so that it disables the security model of > maven, but maybe a warning is to strong and it should rather be an > info level message? > > It might not be obvious to everyone that it's actually the security of > the transport layer that is a key feature, and if that is compromised > it's game over. For example at my place of work some thought that it > didn't matter with https since there was checksums of all the > artifacts. > > I agree that not all repositories have https, but now that lets > encrypt exists it's only a simple configuration tweak to add it, so I > think the improved security of adding https outweights the > inconvenience of it. > > //Alex > > 2016-10-08 11:34 GMT+02:00 Robert Scholte : >> It should be possible to run any build without a warning. We cannot assume >> that every http connection also has a https connection. Maven is only aware >> of one URL and that's the one to Central. This has already been changed to >> https. Other URL's are specified in the settings.xml, (direct) pom.xml and >> dependency-poms. The first two are managed by the end-user, he has set these >> values so he already should be aware of these values. >> The dependency poms (and plugin poms) are harder to discover and to control. >> For all cases having a repository manager is much easier to control >> connections. >> If there should be a warning, might be better to write an enforcer-rule for >> it and apply it on your own projects. >> >> Robert >> >> >> On Sat, 08 Oct 2016 00:49:36 +0200, Manfred Moser >> wrote: >> >>> The aether code is currently absorbed into Maven so you just need to hang >>> tight until thats done if you want to propose a code change. But its right >>> here to the same team. >>> >>> And regarding the warning ... such a warning would have to be disabled by >>> default otherwise it would litter the log for many existing builds causing >>> all sorts of issues. And then I am not sure it makes much sense. >>> >>> But say you go with a warning you would not want to warn for each >>> download but only for the first one to avoid excessive logging. So maybe >>> just warn for each specific repository URL once. >>> >>> Manfred >>> >>> Alexander Kjäll wrote on 2016-10-07 15:42: >>> >>>> Thats good feedback, I'll investigate the aether code and propose the >>>> same thing to them. >>>> >>>> I agree that some people might want to have their download unsecure, >>>> that's why I think that a warning is an appropriate level of >>>> notification regarding this. >>>> >>>> //Alex >>>> >>>> 2016-10-08 0:16 GMT+02:00 Michael Osipov : >>>>> >>>>> Am 2016-10-07 um 23:31 schrieb Alexander Kjäll: >>>>>> >>>>>> >>>>>> Hi >>>>>> >>>>>> I would like to propose that maven issues a warning when an artifacts >>>>>> gets downloaded over http instead of https. >>>>>> >>>>>> The current security model kind of relies on that noone MITM's the >>>>>> download and replaces the artifact and checksums with something >>>>>> malicious. That becomes impossible to guarantee when run over a >>>>
Re: Warning when artifacts are downloaded over an insecure channel
I liked the idea to only issue warnings about repository urls and not for every download, that would greatly reduce the amount of duplicated information. I think it might be user friendly to inform when someone has configured their project so that it disables the security model of maven, but maybe a warning is to strong and it should rather be an info level message? It might not be obvious to everyone that it's actually the security of the transport layer that is a key feature, and if that is compromised it's game over. For example at my place of work some thought that it didn't matter with https since there was checksums of all the artifacts. I agree that not all repositories have https, but now that lets encrypt exists it's only a simple configuration tweak to add it, so I think the improved security of adding https outweights the inconvenience of it. //Alex 2016-10-08 11:34 GMT+02:00 Robert Scholte : > It should be possible to run any build without a warning. We cannot assume > that every http connection also has a https connection. Maven is only aware > of one URL and that's the one to Central. This has already been changed to > https. Other URL's are specified in the settings.xml, (direct) pom.xml and > dependency-poms. The first two are managed by the end-user, he has set these > values so he already should be aware of these values. > The dependency poms (and plugin poms) are harder to discover and to control. > For all cases having a repository manager is much easier to control > connections. > If there should be a warning, might be better to write an enforcer-rule for > it and apply it on your own projects. > > Robert > > > On Sat, 08 Oct 2016 00:49:36 +0200, Manfred Moser > wrote: > >> The aether code is currently absorbed into Maven so you just need to hang >> tight until thats done if you want to propose a code change. But its right >> here to the same team. >> >> And regarding the warning ... such a warning would have to be disabled by >> default otherwise it would litter the log for many existing builds causing >> all sorts of issues. And then I am not sure it makes much sense. >> >> But say you go with a warning you would not want to warn for each >> download but only for the first one to avoid excessive logging. So maybe >> just warn for each specific repository URL once. >> >> Manfred >> >> Alexander Kjäll wrote on 2016-10-07 15:42: >> >>> Thats good feedback, I'll investigate the aether code and propose the >>> same thing to them. >>> >>> I agree that some people might want to have their download unsecure, >>> that's why I think that a warning is an appropriate level of >>> notification regarding this. >>> >>> //Alex >>> >>> 2016-10-08 0:16 GMT+02:00 Michael Osipov : >>>> >>>> Am 2016-10-07 um 23:31 schrieb Alexander Kjäll: >>>>> >>>>> >>>>> Hi >>>>> >>>>> I would like to propose that maven issues a warning when an artifacts >>>>> gets downloaded over http instead of https. >>>>> >>>>> The current security model kind of relies on that noone MITM's the >>>>> download and replaces the artifact and checksums with something >>>>> malicious. That becomes impossible to guarantee when run over a >>>>> transport layer that lacks security. >>>>> >>>>> I have attached a very crude patch that implements this behaviour, but >>>>> I'm sure it needs to be reworked before it's ready to be merged. >>>> >>>> >>>> >>>> Basically, Aether should handle this, as you might plug other protocols >>>> to >>>> pull from: SFTP, FTPS, DAVS, etc. Additionally, if this happens in a >>>> company, maybe people are quite fine with unsecure only. >>>> >>>> To sum up: we should wait when Aether transforms to Maven Artifact >>>> Resolver. >>>> >>>> Michael >>>> >>>> >>>> >>>> - >>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>> >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Warning when artifacts are downloaded over an insecure channel
Thats good feedback, I'll investigate the aether code and propose the same thing to them. I agree that some people might want to have their download unsecure, that's why I think that a warning is an appropriate level of notification regarding this. //Alex 2016-10-08 0:16 GMT+02:00 Michael Osipov : > Am 2016-10-07 um 23:31 schrieb Alexander Kjäll: >> >> Hi >> >> I would like to propose that maven issues a warning when an artifacts >> gets downloaded over http instead of https. >> >> The current security model kind of relies on that noone MITM's the >> download and replaces the artifact and checksums with something >> malicious. That becomes impossible to guarantee when run over a >> transport layer that lacks security. >> >> I have attached a very crude patch that implements this behaviour, but >> I'm sure it needs to be reworked before it's ready to be merged. > > > Basically, Aether should handle this, as you might plug other protocols to > pull from: SFTP, FTPS, DAVS, etc. Additionally, if this happens in a > company, maybe people are quite fine with unsecure only. > > To sum up: we should wait when Aether transforms to Maven Artifact Resolver. > > Michael > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Warning when artifacts are downloaded over an insecure channel
Hi
I would like to propose that maven issues a warning when an artifacts
gets downloaded over http instead of https.
The current security model kind of relies on that noone MITM's the
download and replaces the artifact and checksums with something
malicious. That becomes impossible to guarantee when run over a
transport layer that lacks security.
I have attached a very crude patch that implements this behaviour, but
I'm sure it needs to be reworked before it's ready to be merged.
Do people agree that it would be good to issue those warnings?
best regards
Alexander Kjäll
diff --git a/maven-embedder/src/main/java/org/apache/maven/cli/transfer/AbstractMavenTransferListener.java b/maven-embedder/src/main/java/org/apache/maven/cli/transfer/AbstractMavenTransferListener.java
index e72aa47..32a95a7 100644
--- a/maven-embedder/src/main/java/org/apache/maven/cli/transfer/AbstractMavenTransferListener.java
+++ b/maven-embedder/src/main/java/org/apache/maven/cli/transfer/AbstractMavenTransferListener.java
@@ -19,20 +19,24 @@
* under the License.
*/
-import java.io.PrintStream;
-import java.text.DecimalFormat;
-import java.text.DecimalFormatSymbols;
-import java.util.Locale;
-
import org.apache.commons.lang3.Validate;
+import org.codehaus.plexus.logging.Logger;
+import org.codehaus.plexus.logging.console.ConsoleLogger;
import org.eclipse.aether.transfer.AbstractTransferListener;
import org.eclipse.aether.transfer.TransferCancelledException;
import org.eclipse.aether.transfer.TransferEvent;
import org.eclipse.aether.transfer.TransferResource;
+import java.io.PrintStream;
+import java.text.DecimalFormat;
+import java.text.DecimalFormatSymbols;
+import java.util.Locale;
+
public abstract class AbstractMavenTransferListener
extends AbstractTransferListener
{
+private Logger logger = new ConsoleLogger();
+
// CHECKSTYLE_OFF: LineLength
/**
@@ -219,6 +223,10 @@ public void transferInitiated( TransferEvent event )
String type = event.getRequestType() == TransferEvent.RequestType.PUT ? "Uploading" : "Downloading";
TransferResource resource = event.getResource();
+if ( resource.getRepositoryUrl() != null && resource.getRepositoryUrl().startsWith( "http://"; ) )
+{
+logger.warn( "downloading over insecure transport layer, please use https instead of http." );
+}
out.println( type + ": " + resource.getRepositoryUrl() + resource.getResourceName() );
}
@@ -227,8 +235,8 @@ public void transferCorrupted( TransferEvent event )
throws TransferCancelledException
{
TransferResource resource = event.getResource();
-out.println( "[WARNING] " + event.getException().getMessage() + " for " + resource.getRepositoryUrl()
-+ resource.getResourceName() );
+logger.warn( event.getException().getMessage() + " for " + resource.getRepositoryUrl()
++ resource.getResourceName() );
}
@Override
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
