Support for IPv6 link local #4865
Conversation
|
This is cool! We aren't in a position to merge new features now, and for about 8 weeks. We're doing a Kotlin conversion and that is complex enough that I don't want to make any other changes alongside it. Can you explain how you found yourself using this? I read it in the spec but really want context around how this gets used in practice. |
|
I work for a company which makes network appliances. Using IPv6 link local address solves for example the connection issues when you take the device configured with static IPv4 address from some network and plug it into you LAN with different subnet configured. |
|
Now I'm confused. I was expecting linklocal to be about the local interface. I need to do some studying. In general I'm somewhat reluctant to do this because it opens up attack vectors. |
|
it's definitely about the local interface. To use link local address you must specify the interface. I don't see how it could open up attack vendors. |
|
An attacker server could redirect a client to DoS a server that isn’t on the public internet. |
|
Util.java change will need to target kotlin. Seems like something we could support via caller urls (with some risk), but disallow for automatic redirects. |
|
I'm gonna close this because I'm not ready to impose the security consequences of link local on all of our users. |
|
@swankjesse @yschimke we'd really like okhttp to support link local, since it's really pain for us updating our local fork every time when we need to update okhttp version.. So what's exactly the problem you see here? If it's just you worring about being redirected to different network interface, it can be solved quite easily. Also I can see several other users would like to have this feature in okhttp :) |
|
I'm worried about URLs that would use this feature that currently fail and would soon succeed! This feels like a big security problem. What's the easy solution? |
|
well, I wanted to write that it'll be easy to implement it the way that doesn't allow to switch interfaces by redirections, because that doesn't make much sense anyway. But then I look at the code and found out that it's already implemented that way :) Is not allowing redirects to switch network interfaces for traffic enough for you to stop worrying about security? |
|
I don't want new calls to switch interfaces either. Imagine crawling the web with OkHttp and a malicious page attempts to get the crawler to index URLs on it's internal interface. |
|
is this really a security issue which should be okhttp client library worried about? Isn't it more about good/bad crawler implementation? I am not proposing okhttp to support some custom hacky protocol, just RFC documented addressing :) |
|
Do browsers support this? If they do we should; if they don't we shouldn't. |
|
Looks like the answer is no. |
|
Also! Not supporting link local addresses URLs does not mean OkHttp cannot access the resources at those URLs! You just need to specify a SocketFactory that chooses the link you want. That's not too much code and it keeps this feature safe. |
|
@marsounjan What's the typical use case for this? Any examples of where you need it for typical development or app uses? |
#1706